On Tue, Mar 13, 2018 at 01:38:24PM +0100, Tom Gundersen wrote:
On Fri, Feb 23, 2018 at 7:59 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
> On Fri, Feb 16, 2018 at 12:13:15PM +0100, Jan Kurik wrote:
>> Proposed System Wide Change: Enable dbus-broker
>>
https://fedoraproject.org/wiki/Changes/EnableDbusBroker
>
> What about renaming this to DbusBrokerAsTheDefaultDbusImplementation?
>
> "Enable" correctly describes the technical operation (systemctl
invocation),
> but it isn't obvious just from the title that this is about replacing
> normal dbus daemon.
Will do.
>> == Scope ==
>> * Proposal owners:
>> ** Fix regressions.
>> ** Enabledbus-broker.service in system and user-global context of
>> systemd (via systemd presets).
>
>> ** Pull in dbus-broker package from dbus package.
> I'm not sure if this is the correct way to do this. People might want
> to install systems with just normal dbus (e.g. in containers or minimal
> installations). It'd be better to update comps [1] to pull in dbus-broker
> instead of dbus into @Standard.
>
> [Based on our preeliminary discussions]
> This replaces the system wide bus and user busses.
> What about the at-spi2 private dbus instance?
I have submitted a patch to enable at-spi2 to use dbus-broker in
addition to dbus-daemon.
> Would dbus-broker be fast
> enough to change gdm to use the user bus?
/gdm/at-spi2/ ?
Yes, not sure what happened there.
A priori, I would have thought so, but I have not tried to reproduce
their benchmarks, so I can't say for certain.
> Do you have plans to replace this last use too?
It is certainly possible, but I see this as an orthogonal issue to
providing the system/user bus so it is not something we have looked
into (apart from making sure it is possible), and ultimately it is up
to the at-spi2 maintainers what bus implementation they want to depend
on.
FTR:
https://github.com/GNOME/at-spi2-core/pull/2
From the point of view of the whole distro, it makes a lot of sense to
switch all uses. Maybe not all at once, to make it easier to diagnose
regressions, but in the long term. Carrying two implementations increases
the disk and memory footprint, the attack and bug surface, the number
of updates, and hence the amount of testing. In this case none of those
costs are very big, but since dbus runs pretty much everywhere, it still
makes sense to (plan to) minimize them.
> If dbus-broker becomes the default like described in the Change
page,
> what other dependencies on dbus will remain?
On the daemon itself, none to my knowledge (assuming my at-spi2 patch
is merged).
Great! That's the answer I was hoping for ;)
> Since this is already testable [2], what about asking for
testing on
> devel-announce@ and test-announce@ ? This is a pretty big change, and
> I don't we can make the decision to use this by default without
> widespread testing.
Will do.
Zbyszek