On Sun, 11 Aug 2019, Simon McVittie wrote: > Found while preparing a test VM to test #923240. Please raise this to > RC severity if you think it is justified - I don't want to create the
I don’t think it’s RC in any of the involved packages (elogind, systemd (shock!), apt) because it’s really a whole-system / package management issue. > Actual result (transcript below): > > * systemd-sysv is removed > * sysvinit-core is unpacked > * systemd is also removed > * systemd's prerm fails because it is still the active init system Interesting. But this probably happens before the preinst of libelogind0 and does prevent its installation, which is not something easily circumvented. > (this check is present since Debian systemd commit c3f5f249 in 44-6, > released in 2012 - it appears the intention is that anyone wishing to > switch from systemd to sysvinit should replace systemd-sysv with > sysvinit-core, then reboot into sysvinit, and only (auto)remove > systemd after that reboot) Yes but see below. > Maybe libelogind0 and elogind would be better off having Breaks (inverse > Depends) relationships with their systemd equivalents, instead of > Conflicts (inverse Pre-Depends) which are maybe too strong? Conflicts is needed since there are file-level conflicts; otherwise, the files from libelogind0 would vanish. > Maybe libelogind0 should install into a different directory, and use > maintainer scripts (perhaps involving dpkg-divert) to get itself to be > loaded instead of libsystemd, so that it doesn't have to have file-level > conflicts with libsystemd at all? Might be a path worth looking at, but… > Maybe libelogind0 should have (Conflicts or) Breaks on libpam-systemd and > systemd-sysv, but not on systemd, because packages that depend on a > working systemd-logind are meant to depend on libpam-systemd and not just > systemd? … just like this one, both won’t _really_ work: they’d allow the installation to continue, but the system is not rebootable afterwards either. We cannot even use a Pre-Depends on a non-systemd init, because… see below. > The only way I have managed to migrate systems reasonably cleanly is to boot > with init=/bin/sh, replace systemd with whatever else and then reboot again. > But > as you point out, that is not the obvious migration route that a normal > sysadmin > might take. > > The problem is that the route recommended in #930105 (et al.) is to first > install sysvinit-core, reboot and then remove systemd. The first step of this > will require removal of almost the entire GUI environment -- something few > would > persist with even though it could all be reinstalled later. Hmm, interesting… had not thought of that (you’d probably have to do that on systems before installing anything desktop-y, or use my unofficial packages in the middle). But TTBOMK it is possible to install sysvinit alongside systemd, then reboot and select sysvinit as “alternative” init from the GRUB menu, then remove everything else. Now that I see /sbin/init is part of sysvinit-core, I wonder if this is really possible any more and, if not, why not… packages are not supposed to depend on systemd-sysv… (but, ouch, libpam-systemd does). On the other hand, libpam-systemd Provides logind, so I guess it is one of the packages replaced by elogind. So some kind of transition and cross-package/maintainerscript communication is needed. And no matter what route is chosen, something will always break in an intermediate state (even the Depends from libpam-systemd on systemd-sysv will not ensure that systemd is actually the init system currently running, or used at next boot). This bears more thought. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ********** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **********
