On Tue, Dec 31, 2013 at 01:07:22PM -0800, Steve Langasek wrote: > On Tue, Dec 31, 2013 at 01:16:32AM -0800, Josh Triplett wrote: > > Steve Langasek wrote: > > > Looking more closely, I find that one of the conflicting files is a > > > conffile > > > (/etc/dbus-1/system.d/org.freedesktop.systemd1.conf). diversions and > > > conffiles still don't mix, AFAIK (and according to current policy). So > > > that > > > seems to still leave us without a proper solution that doesn't involve > > > splitting the systemd binary package. > > > Files in /etc/dbus-1/system.d/ need not have names that match the > > interface they control; see, for instance, gdm.conf or > > nm-dhcp-client.conf. Why not simply install a systemd-shim.conf with > > the contents you need? To the best of my knowledge, I see nothing in > > org.freedesktop.systemd1.conf that should interfere with you. > > I hadn't considered that, but yes, I see that it's true that we could > install the conffile under a different name. > > Given that the two config files apply policy to the same dbus name, this > means that a removed-but-not-purged systemd-shim package may impact > systemd's own dbus security policy. It's already the case that the > systemd-shim and systemd policies are different.
Interesting; why are those policies different? systemd's policy is, as far as I can tell, "root can do as it likes, root can receive activation requests, anyone else can send specific requests". Is systemd-shim's policy more lax or more strict? > So, which is the lesser evil here - that a removed-but-not-purged > systemd-shim package will interfere with the dbus policy of systemd itself, > or that an installed-then-purged systemd-shim package will remove the > systemd dbus policy altogether? The latter, quite clearly. Both would be bugs in systemd-shim, but removing the configuration entirely would break systemd with the systemd-shim package *not* installed, while interfering with the configuration would break systemd with the systemd-shim package *installed*, which seems less egregious and less surprising. > > (That said, personally I'd prefer to see systemd-shim continue to > > conflict with systemd, and work with a hypothetical > > forked-systemd-logind package instead, which would also conflict with > > systemd. That would then, for instance, unblock systemd's ability to > > upgrade past version 204.) > > For the record, logind is not the only issue here. It's logind, timedated, > hostnamed, localed which are needed by GNOME. This doesn't actually change > the work involved in forking the package; but I think it would be ridiculous > to have two systemd source packages in the archive, with all the resulting > coordination costs to both maintainers, instead of working out a correct > binary split of the one package that meets the needs of all Debian's users. The key phrase is "both maintainers". Having two packages that permanently conflict with each other hardly seems like a major coordination effort. (The only annoyance I can think of is that I don't know of any way to conflict with a package such that even having it removed-but-not-purged would prevent installation of the conflicting package.) The problem is not the binary split, it's the ongoing maintenance burden of making components of systemd run without systemd. I would like to see the forked-systemd source package maintained by folks willing to do that work, and in the meantime, I'd like to see an *un*-forked systemd package usable by people who want and use systemd. (I'd be quite willing to help with the latter, especially if the systemd maintainers find themselves shorthanded due to demotivation caused by an upcoming tech-ctte decision.) In particular, I'd like to see new versions of systemd available in Debian as soon as they're available upstream, and that seems highly unlikely to happen with a forked systemd. I'd also like to avoid a situation in which the only package of systemd in the archive is maintained as a permanent fork by people who don't actually use it as their init systemd; that would not bode well for people trying to run it and have their systems depend on it. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
