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