[arch-general] [arch-dev-public] [RFC] dbus cleanup

[Leonid Isaev]

On Mon, 03 Dec 2012 12:59:47 -0500
"Daniel F. Savarese" <dfs at savarese.org> wrote:

> 
> In message
> <CAG-2HqUx+=R59_24ytS6JefkXWR9qCzfTBXuVi_S_9bxbF83fQ at mail.gmail.com> , Tom
> Gundersen writes:
> >I'd like to propose the following change to our two dbus packages:
> >
> > * make libx11 an optdep in dbus
> > * merge dbus-core into dbus
> > * move dbus to [core]
> >
> >This should not have much of an effect in practice, but should make
> >things a bit clearer and especially the naming will be more in-line
> >with upstream and other distros.
> 
> For myself, and anyone else administering large numbers of dbus-free systems
> (defined as having no running dbus daemons) running Arch Linux (perhaps I'm
> the only one?), it adds a maintenance burden.  Currently, because of the

If you don't run dbus, just update routinely and pacman will figure out which
packages to keep. Since dbus 1.6.8-3 conflicts and provides dbus-core, the
latter will be removed.

> incorrect package dependencies you mention, I have to remove the dbus package
> from every system after an update.  That extra step is inconvenient, but
> manageable via automation.  If you merge the two packages, what am I supposed
> to do?  I can't simply remove /usr/bin/dbus-launch and
> /etc/X11/xinit/xinitrc.d/30-dbus because that defeats system versioning via
> package management.  That means I have to either maintain a custom dbus
> package that omits dbus-launch or add a klugey NoExtract directive to

NoExtract'ing 30-dbus and dbus-launch is not necessary because (a) They are
harmless if dbus is not run; (b) 30-dbus is harmless even with a DE which is
properly started from .xinitrc (I haven't even known about 30-dbus until
today).

> pacman.conf on all systems.  I say klugey because names and locations of
> files can change over time, making NoExtract fail silently and therefore
> requiring one to test for such changes as part of one's system updating
> procedures.  That's why I maintain custom packages (60+ and counting)
> instead of using more fragile alternatives.
> 
> >We can see that the current naming has caused some confusion as most
> >of the packages that depend on dbus should in fact be depending on
> >dbus-core.
> 
> My understanding (which may be incorrect) was that the separate packages
> were created to allow users to opt out of having dbus-launch on their
> systems to prevent programs from starting dbus-daemon willy nilly.
> (If the same can be achieved via setting DBUS_SESSION_BUS_ADDRESS to
> /dev/null then my objection is largely moot, even though setting that
> environment variable is not a clean solution for my use case).  Of course,
> incorrect package dependencies defeat that goal, requiring one to forcibly
> remove the dbus package when not required.  It seems pretty clear that if
> the problem you're trying to solve is incorrect package dependencies, the
> correct solution is to correct the package dependencies, not to change the
> packaging.  By merging the packages you're indicating you no longer want
> to make it easy for users to remove dbus-launch.  That's your prerogative,
> but I ask you to evaluate whether you really want to do that.  Supposing
> you don't want to do that, as an alternative I suggest that you rename the
> dbus package to dbus-launch and dbus-core to dbus (or just leave it as
> dbus-core) to resolve package naming confusion.  Supposing there are no
> longer enough dbus-avoiding users to justify keeping the packages separate,
> then I ask you warn users in advance of the change so that people have an
> opportunity to take the steps required to keep their systems running as
> expected before an update surprises them.

With systemd you can't avoid dbus and you can't avoid systemd. Therefore, dbus
must be present. Note that on a server dbus-launch will not even start since
you will not have libx11, and dbus-launch links to it.

> 
> daniel
> 



-- 
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20121203/aaa96728/attachment.asc>