Sam, Since I cannot get a working and robust dpkg-divert solution, I feel the need to revisit the validity of these concerns.
On Mon, Sep 23, 2019 at 03:03:57PM -0400, Sam Hartman wrote: > >>>>> "Mark" == Mark Hindley <m...@hindley.org.uk> writes: > >> If we are going to use c/r/p libsystemd0, is there some way we > >> can limit the potential damage to people who have positively > >> indicated that they want to run a non-default init system? One > >> of the concerns is what happens if apt decides somehow that it > >> wants to install libelogind0 when you don't expect it. > > Mark> I have to admit I don't understand this fear. libsystemd0 is > Mark> just a way of talking to a running systemd process. If systemd > Mark> is not running and PID 1 libsystemd0 APIs generally return non > Mark> fatal errors. So by running a non-default init, libsystemd0 is > Mark> only there to satisfy dynamically loaded symbols at > Mark> runtime. Otherwise it is basically non functional. libelogind0 > Mark> is the same if elogind isn't running. > > Foo-package depends on the latest libsystemd0. I'm running unstable or > testing. The latest libsystemd0 isn't building on my arch yet. But > elogind is simpler and has build fine on my arch. I install foo-package > and suddenly end up with libelogind0 instead of libsystemd0 > > This is probably a problem. > Libsystemd0 and libelogind0 probably behave differently and you probably > do care which one you have. Yes, it would be a problem if that was what happened, but if this system had systemd installed, the current dependencies do not allow it. If systemd wasn't installed it might happen. However, I don't think that would cause any change in function. There appears to be some mystique as to what libsystemd0 and libelogind0 do. Their only function is to provide library API access to a running systemd or elogind process. In the absence of that, they do nothing beyond satisfying the runtime linker. > The specific problems depend on what init system I have, on whether I > have elogind running or systemd-logind, etc. > But it's probably not a good situation. Yes, so problems and loss of functionality are caused only if you end up with the combination systemd/libelogind0 or elogind/libsystemd0. Current dependencies make the first of these impossible and second one is what we are trying to provide a solution to. To be sure, I have just tried to install libelogind0 on a sid VM booted with systemd. APT will not let you do it requiring you to type the 'Yes, do as I say!' phrase after its serious warning which is surely enough to dissuade most people from proceeding. The dependency stack is init (Priority: important) PreDepends systemd-sysv systemd-sysv (Priority: important) PreDepends systemd libelogind0 conflicts systemd Given that, I can see no way libelogind0 could accidentally be installed on a system with systemd. It is possible to get APT to attempt a solution by specifically requesting 'apt install libelogind0 sysvinit-core'. This removes systemd-sysv and then fails gracefully when the systemd prerm fails. 'apt -f install' successfully cleans up by configuring sysvinit-core. This would only be specified by a user wanting to switch to an non-default init and is not going to happen by accident. Importantly in this scenario, libelogind0 is still not installed and the system including systemd as init still functions. If you realise you have made a mistake you can even return to systemd-sysv just by reinstalling it. I hope you don't feel I am going over old ground here, but I fail to see a case that is not covered. What am I missing? Mark
