On Mon, 03 Dec 2012 12:59:47 -0500 "Daniel F. Savarese" <dfs@savarese.org> wrote:
In message <CAG-2HqUx+=R59_24ytS6JefkXWR9qCzfTBXuVi_S_9bxbF83fQ@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