Bug#729576: Bug#727708: systemd-shim uploaded to NEW

[Josh Triplett]

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