On Fri, Feb 23, 2018 at 7:59 PM, Zbigniew Jędrzejewski-Szmek
> On Fri, Feb 16, 2018 at 12:13:15PM +0100, Jan Kurik wrote:
>> Proposed System Wide Change: Enable dbus-broker
> 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.
>> == 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  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?
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
> 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
> Since this is already testable , 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.
devel mailing list -- email@example.com
To unsubscribe send an email to devel-le...@lists.fedoraproject.org