On Mon, 03 Dec 2012 12:59:47 -0500 "Daniel F. Savarese" <dfs@xxxxxxxxxxxx> wrote: > > In message > <CAG-2HqUx+=R59_24ytS6JefkXWR9qCzfTBXuVi_S_9bxbF83fQ@xxxxxxxxxxxxxx> , 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
Attachment:
signature.asc
Description: PGP signature
