Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)
On Tue, 05 Dec 2017 at 12:26:43 +0100, Julian Andres Klode wrote: > More importantly, several packages now require just systemd-sysv. If > apt is told to install libpam-systemd and such a package in the same > operation (especially in a chroot I'd say, since that's where neither > shim nor sysv is installed), it may fail to resolve dependencies > because it picks systemd-shim first and fails to replace it with > systemd-sysv later. Another fun failure mode is that if a dependency chain in a buildd chroot involves libpam-systemd (the one I experienced today was GTK+ 3 pulling in dconf-service, which depends on a working D-Bus session bus, and our recommended implementation of one of those depends on systemd), you'll currently get systemd-shim. This depends on several orphaned or undermaintained packages, one of which (libnih) uses glibc internal symbols that make it uninstallable-until-binNMU'd with every new version of glibc. Again, the current apt resolver commits to installing systemd-shim and doesn't unwind far enough to be able to replace it with systemd-sysv when systemd-shim turns out to be uninstallable. As a general goal, it seems bad to have orphaned packages with no upstream developer be in the critical path for building unrelated software. smcv
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 +, 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 +, 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
Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)
Control: reassign 883555 systemd-shim
Control: retitle 883555 systemd-shim should be Multi-Arch: foreign
On Tue, Dec 05, 2017 at 06:19:28PM +, 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 +, 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.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)
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.
> > 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 +, 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 ?
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)
On Tue, Dec 05, 2017 at 06:48:45PM +0100, Julian Andres Klode wrote: > gpsd netbase | systemd-sysv > mandos systemd-sysv | lsb-base (>= 3.0-6) > micro-httpd openbsd-inetd | inet-superserver | micro-inetd | netcat-traditional | systemd-sysv > munin cron | cron-daemon | systemd-sysv -- WBR, wRAR signature.asc Description: PGP signature
Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)
On Tue, 05 Dec 2017, Julian Andres Klode wrote: > On Tue, Dec 05, 2017 at 05:36:10PM +, 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 netbase|systemd-sysv > mandos systemd-sysv|lsb-base > micro-httpd openbsd-inetd | inet-superserver | micro-inetd | netcat-traditional | systemd-sysv > munin cron|cron-daemon|systemd-sysv > numad systemd-sysv | cgmanager > prometheus daemon | systemd-sysv > prometheus-node-exporter daemon | systemd-sysv Most of these either need cgroups or inetd equivalents. > runit-systemd > systemd-cron These are all systemd related > pk4 > freeipa-server > tinysshd These seem to be the only three which depend on systemd-sysv, and I'm not really sure why any of them actually Depend on it. -- Don Armstrong https://www.donarmstrong.com The smallest quantity of bread that can be sliced and toasted has yet to be experimentally determined. In the quantum limit we must necessarily encounter fundamental toast particles which the author will unflinchingly designate here as "croutons". -- Cser, Jim. Nanotechnology and the Physical Limits of Toastability. AIR 1:3, June, 1995.
Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)
On Tue, Dec 05, 2017 at 05:36:10PM +, Ian Jackson wrote:
> Don Armstrong writes ("Bug#883573: Reevaluate libpam-systemd systemd-sysv
> dependency ordering (746578)"):
> > On Tue, 05 Dec 2017, Julian Andres Klode wrote:
> > > I thus opened bug 883569 against systemd, but mbiebl would like to
> > > get permission from the you first.
>
> I think it would be sensible for the TC to explicitly grant or
> withhold permission.
>
> > As systemd-shim does not (appear to?) have an active maintainer, and
> > this should be moot for stretch->buster, I don't personally see a
> > problem. [Perhaps a NEWS entry or something in the release notes might
> > be a nice gesture?]
>
> FAOD, I regard myself as a caretaker for system-shim.
Then please adopt the package?
>
> > Does anyone have a counter-argument?
>
> I don't. The argument presented in the head article seem to make
> sense to me. But I don't feel I understand all the implications.
>
> 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
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.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)
On Tue, Dec 05, 2017 at 05:36:10PM +, Ian Jackson wrote: > One question I have is about this: "several packages now require just > systemd-sysv". Can someone refer to some examples, please ? Third random try from `reverse-depends systemd-sysv` yielded lava-server. -- WBR, wRAR signature.asc Description: PGP signature
Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)
Don Armstrong writes ("Bug#883573: Reevaluate libpam-systemd systemd-sysv
dependency ordering (746578)"):
> On Tue, 05 Dec 2017, Julian Andres Klode wrote:
> > I thus opened bug 883569 against systemd, but mbiebl would like to
> > get permission from the you first.
I think it would be sensible for the TC to explicitly grant or
withhold permission.
> As systemd-shim does not (appear to?) have an active maintainer, and
> this should be moot for stretch->buster, I don't personally see a
> problem. [Perhaps a NEWS entry or something in the release notes might
> be a nice gesture?]
FAOD, I regard myself as a caretaker for system-shim.
> Does anyone have a counter-argument?
I don't. The argument presented in the head article seem to make
sense to me. But I don't feel I understand all the implications.
One question I have is about this: "several packages now require just
systemd-sysv". Can someone refer to some examples, please ?
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)
On Tue, 05 Dec 2017, Julian Andres Klode wrote: > More importantly, several packages now require just systemd-sysv. If > apt is told to install libpam-systemd and such a package in the same > operation (especially in a chroot I'd say, since that's where neither > shim nor sysv is installed), it may fail to resolve dependencies > because it picks systemd-shim first and fails to replace it with > systemd-sysv later. See #883555 for an example. This is a definitely a bug in apt's resolver, but it wasn't a problem originally because systemd-sysv did not have a Conflicts: systemd-shim. > I thus opened bug 883569 against systemd, but mbiebl would like to > get permission from the you first. As systemd-shim does not (appear to?) have an active maintainer, and this should be moot for stretch->buster, I don't personally see a problem. [Perhaps a NEWS entry or something in the release notes might be a nice gesture?] Does anyone have a counter-argument? -- Don Armstrong https://www.donarmstrong.com Love is... a complex sequence of neurochemical reactions that makes people behave like idiots. It's similar to intoxication, but the hangover's even worse. -- J. Jacques _Questionable Content_ #1039 http://www.questionablecontent.net/view.php?comic=1039
Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)
Hi Julian, Le mardi, 5 décembre 2017, 12.26:43 h CET Julian Andres Klode a écrit : > In 746578, the CTTE decided that the dependency be swapped > to systemd-shim | systemd-sysv in order to prevent systems > from being upgraded installing systemd. > > (…) > > I thus opened bug 883569 against systemd, but mbiebl would like to > get permission from the you first. Thank you for filiing this bug. This is just a short answer to acknowledge it as well as provide visibility upon the timeframe for its resolution. As you might be aware from discussions on the debian-ctte@l.d.o list, we are currently discussing seat-filling, both concretely and meta, so our energy is spread accross these topics already. Also, December is notorious for being a dense period in the year for many, TC members included. My hope is that the TC will be able to spend enough energy to get this ball rolling, with a resolution somewhere in January. With my best regards, OdyX
Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)
Package: tech-ctte Severity: normal Control: block 883569 by -1 Dear CTTE, In 746578, the CTTE decided that the dependency be swapped to systemd-shim | systemd-sysv in order to prevent systems from being upgraded installing systemd. This argument should be moot now. Either dependency is satisfied on systems now, so an upgrade won't change anything. More importantly, several packages now require just systemd-sysv. If apt is told to install libpam-systemd and such a package in the same operation (especially in a chroot I'd say, since that's where neither shim nor sysv is installed), it may fail to resolve dependencies because it picks systemd-shim first and fails to replace it with systemd-sysv later. See #883555 for an example. I thus opened bug 883569 against systemd, but mbiebl would like to get permission from the you first. > Package: libpam-systemd > Version: 235-3 > Severity: important > > libpam-systemd depending on systemd-shim first causes severe trouble with > resolving dependencies, as APT picks systemd-shim but then later sees a > package which needs systemd-sysv and fails. > > I understand the order was necessary for preventing upgrades to stretch > from migrating to systemd, but with the packages now widely installed, > this should not be a problem anymore, as the dependencies are satisfied > already, so APT won't switch them. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (100, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
