On Thu, Jun 04, 2020 at 09:24:22PM +0300, Aleksey Tulinov wrote: > On Wed, 9 Oct 2019 17:36:07 +0200 David Kalnischkies > <david@kalnischkies.de> wrote: > > As Julian already said, it is "just" used for its dbus communication > > implementation. We don't require systemd to be your init or to be even > > functional. So I guess proposing an alternative which a) works equally > > well and b) doesn't add additional bootstrapping complications has > > better chances of acceptance – assuming that exists as the obvious > > choice libdbus links against libsystemd as well even before checking a) > > and b) … > > > > I'm not a big expert in systemd and never will be, but perhaps > `systemd-inhibit --what="shutdown" --mode="block" apt ...` should do > about the same thing. If every invocation of apt should be like that > then maybe `alias apt='systemd-inhibit --what="shutdown" > --mode="block" apt'` in .bashrc can do the trick. This does not > require any patching whatsoever. I mentioned already that this is implemented in libapt to apply to ALL apt-based clients equally. A cron-job is not effected by aliases nor is a python script (using python-apt). It isn't even realistic that you alias all "normal" libapt clients like apt, apt-get, aptitude, synaptics, various desktop-environment-specific software centers … Especially as its usually not the interactive sessions as everyone who has started an apt action by hand usually has the decency to wait for it to finish before asking the system to shutdown. Just like nobody starts two or more apt actions in parallel by hand. But cronjobs and background processes do, so we got frontend lock, waiting for lock release or the shutdown inhibition in question here (and of course, it turns out given enough users some actually do all of this anyway because why not). > This linking to libsystemd is redundant. If issue is with dpkg leaving It might be redundant – in the best case. Balint already mentioned that being the case for unattended-upgrades and that is probably a good idea for a client (for the same reason I will mention below in the apt ↔ dpkg relationship), but not every client will realistically implement it as not every client is that involved. > system in inconsistent state when interrupted, then perhaps this issue > has to be fixed in dpkg, if issue is with systemd incorrectly > interrupting dpkg, then in systemd. I think that dependency on Shutdown is inhibit. That means your system (← no "d") is prevented from shutting down before the last action inhibiting shutdown is done. dpkg can inhibit shutdown and perhaps it should¹, but it can only do so while it is running. libapt potentially runs dpkg multiple times, so if we don't inhibit your system might shutdown between two dpkg calls. The system state isn't inconsistent in a package manager sense in such cases, it might "just" not be able to boot in that state (even if relatively unusual). For much the same reason libapt inhibits the termination signal (^C) to stop at a consistent state, but a system being shut down eventually kills processes which take to long and that can of course not be inhibited. (¹ dpkg is essential though, so it can't just use and depend on something and its not usually run directly in the background so its less of an issue to begin with) > So it doesn't do much anyway, it attempts to solve some very specific > issue in very specific environment, but it doesn't do that very well > and can be replaced with one shell alias. So, as explained, yes, the issue is specific and "solved" only in specific environments (= those which allow shutdown to be inhibited programmatically), but so far nobody told us how to solve it for more environments or with library&code with less downsides and I hopefully explained above why "one shell alias" does not solve anything. > It would be really nice if this dependency is removed and ideally And I have to repeat: This dependency removes itself if your distribution and/or architecture does not have libsystemd while apt is being built as evident by the non-linux architectures Debian has. So it would be really nice if we would get some more reason than just some OCD-level "but but but, the word 'systemd' is in there somewhere" arguments for making maintenance of apt harder (via e.g. dlopen) or it just wont happen as building apt is trivially easy and can be fully automated, but maintaining and supporting it can't be. Best regards David Kalnischkies, who wonders if its Baader-Meinhof that since he started with resolver changes triggered by runit seemingly things involving the names of init systems pop up everywhere around him.
Attachment:
signature.asc
Description: PGP signature