[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposed mass bug filing: use and misuse of dbus-launch (dbus-x11)



On Thu, 28 Jul 2016 at 08:33:21 -0400, Marvin Renich wrote:
> * Simon McVittie <smcv@debian.org> [160727 20:04]:
> > On Wed, 27 Jul 2016 at 18:02:32 +0200, Laurent Bigonville wrote:
> > > Shouldn't this
> > > dependency only be declared at some other level (libdbus, GDBus,...)?
> > 
> > I think this would have to be a new dbus-session metapackage, unless
> > I'm missing something. dbus is the wrong place, and so are all the
> > obvious libraries.
> 
> Do you mean metapackage or virtual package?  Wouldn't a virtual package
> be exactly the right thing for this?  Then dbus-user-session and
> dbus-x11 would each "Provides: dbus-session" and no additional real
> package is required.  Maybe I do not understand what is being suggested.

If we want to avoid mass package changes when the preferred way to get
a session bus changes, then either it has to be a real package, or we
have to have a real dbus-default-session-bus package instead.

When there are two or more providers for a virtual package, dependening
packages need to depend on a real package, with a virtual package as
an alternative. If we just had

    Package: empathy
    Depends: dbus-session-bus

    Package: dbus-x11
    Provides: dbus-session-bus

    Package: dbus-user-session
    Provides: dbus-session-bus

where dbus-session-bus was virtual, then installing Empathy on a bare
system would give you randomly chosen session bus semantics, either
dbus-user-session or dbus-x11. I don't think that's at all useful.

If we have

    Package: empathy
    Depends: dbus-user-session | dbus-session-bus

    Package: dbus-x11
    Provides: dbus-session-bus

    Package: dbus-user-session
    Provides: dbus-session-bus

and we later decide that actually, the preferred implementation of
dbus-session-bus is kdbus-user-bus, then we'd have to patch Empathy
(and all other packages in the same situation) to have that preference,
which is just as many changes as those that Josh and Laurent were
concerned about.

If dbus-session-bus is a real package:

    Package: dbus-session-bus
    Depends: dbus-user-session | dbus-x11

    Package: empathy
    Depends: dbus-session-bus

    Package: dbus-x11
    Provides: dbus-session-bus

    Package: dbus-user-session
    Provides: dbus-session-bus

then I think everything works the way we'd want? New installations
get dbus-user-session, existing installations get dbus-x11 (and if
we want a heavier hint to switch to dbus-user-session, we could
maybe use Recommends).

Another option, with an extra real package: if we have

    Package: dbus-default-session-bus
    Depends: dbus-user-session

    Package: dbus-x11
    Provides: dbus-session-bus

    Package: dbus-user-session
    Provides: dbus-session-bus

    Package: empathy
    Depends: dbus-default-session-bus | dbus-session-bus

then the dependency graph is a bit more complicated, and I think all
we've gained is the ability to switch people from one implementation to
another at upgrades? This is appropriate where there's a clear "best"
implementation, like the default Python or JDK version, but I don't
think that's necessarily the case here.

    S


Reply to: