Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)
On Tue, Dec 05, 2017 at 09:32:19PM +0100, Julian Andres Klode wrote:
> Control: reassign 883555 systemd-shim
> Control: retitle 883555 systemd-shim should be Multi-Arch: foreign
>
> On Tue, Dec 05, 2017 at 06:19:28PM +0000, Ian Jackson wrote:
> > Julian Andres Klode writes ("Re: Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)"):
> > > I think another major problem (with bug 883555) though is that systemd-shim
> > > is not Multi-Arch: foreign like systemd-sysv. In that case, systemd-shim was
> > > first marked for install, but then for removal as systemd-shim:foreign was to
> > > be installed. And then it picked systemd-sysv somehow. In summary, libpam-systemd:foreign
> > > is currently not installable if systemd-shim is installed.
> >
> > I think that perhaps systemd-shim should be marked M-A foreign. Its
> > function is to provide a dbus service which AIUI is not
> > architecture-dependent. I can easily upload such a change at this
> > stage of the buster cycle.
>
> Please do so, I think that's probably the major issue. I'm reassigning helmut's
> bug to systemd-shim, as that should fix that specific issue.
>
> >
> > > > FAOD, I regard myself as a caretaker for system-shim.
> > >
> > > Then please adopt the package?
> >
> > I definitely don't feel the sense of knowledge or ownership that would
> > be appropriate for that.
> >
> > > On Tue, Dec 05, 2017 at 05:36:10PM +0000, Ian Jackson wrote:
> > > > One question I have is about this: "several packages now require just
> > > > systemd-sysv". Can someone refer to some examples, please ?
> > >
> > ...
> > > $ grep-aptavail -FDepends systemd-sysv --and --not -FDepends systemd-shim -nsPackage | grep -v ^jak
> > > friendly-recovery
> > > gpsd
> > > mandos
> > > micro-httpd
> > > munin
> > > numad
> > > pk4
> > > prometheus
> > > prometheus-node-exporter
> > > runit-systemd
> > > systemd-cron
> > > gpsd
> > > micro-httpd
> > > numad
> > > pk4
> > > prometheus
> > > prometheus-node-exporter
> > > systemd-cron
> > > freeipa-server
> > > tinysshd
> > > tinysshd
> >
> > What ? Why do these packages depend on system-sysv ? (I mean, for
> > systemd-cron it's kind of obvious but for most of the others it is
> > not.) I checked gpsd as that was something I thought I knew something
> > about and that Depends on netbase | systemd-sysv, which is rather
> > different and seems OK.
> >
> > I reran your search in sid with --not -FDepends netbase and got a
> > shorter list.
> >
> > freeipa-server
> > friendly-recovery
> > lava-dispatcher
> > lava-server
> > mandos
> > micro-httpd
> > munin
> > numad
> > pk4
> > prometheus
> > prometheus-node-exporter
> > runit-systemd
> > systemd-cron
> >
> > That still seems to have quite a few false positives (micro-httpd,
> > mandos), as well as some minority packages that seem to have gained or
> > maybe always had unfortunate specific init system dependencies
> > (freeipa-server, friendly-recovery). I haven't investigated them in
> > detail.
> >
> > Do you have an example package that is causing the installation
> > failure ?
>
> I don't have any example. DonKult says he's seen a lot of issues,
> so he should comment on that. I'm not sure how far they are also
> just caused by systemd-shim not being m-a foreign.
>
> We generally request that dependencies in an or group have the same
> order (so if one has A | B and the other B, that's a different order),
> as that can cause problems in unexpected places when using our
> crappy solver, especially if they are at a low level.
That said, one approach mbiebl proposed in #debian-systemd which might
be better anyway is to swap the dependency order in libpam-systemd and
mark systemd-sysv and sysvinit-core with XB-Important: yes.
This should have the effect actually intended: Prevent accidental
init switching, while still pulling in systemd-sysv on systems
that don't have an init, but depend on systemd-shim | systemd-sysv.
To switch an init, a user likely would have to pass
--allow-remove-essential to apt. We should have a different
flag for XB-Important, but that depends on it getting a final
official name...
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Reply to: