>>>>> "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. 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. The concern is there might be other cases where the dependency resolver gives you an answer that is inappropriate for your environment. We're not sure we have confidence we can enumerate and think about all these situations. This is less likely with things like mail-transport-agent because the dependencies are closer to their usage, or because the size of the interacting parts of the dependency graph are smaller.