пт, 5 июн. 2020 г. в 00:30, David Kalnischkies <da...@kalnischkies.de>:
> 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 … > Am i right that dpkg is invoked as a process anyway, even without a shell, it's going to be something like "dpkg --args --args --etc --etc"? But it's going to spawn a process, right? Why not make dpkg invocation on Debian into systemd-inhibit --what="shutdown" --mode="block" /internal/path/to/dpkg $@ and let it be something else in other distros? This won't create dependency on libsystemd0 and will allow to perform extra actions on dpkg invocations that are going to happen regardless if dependency on libsystemd0 exists or not. And if you want something that works <quote> equally well <end quote> to systemd's inhibit, why not use systemd-inhibit in the first place? This dbus voodoo looks a lot like a race condition to me anyway. If systemd-logind is going down before dpkg can send out dbus message, which probably can happen during shutdown, who's going to process this message and inhibit shutdown? `Inhibitor` doesn't do anything with returned `Fd`, error code from systemd call is handled and returned, but then ignored, this looks to me like it just hopes that shutdown is inhibited after the call, which might or might not be true. Although i'm just skimming through the source code and might be missing something, but i don't see this in `pkgDPkgPM::Go()` at all. I suppose it should at least return false if `inhibitor` couldn't place inhibit. I'm looking at source code here: https://github.com/Debian/apt/blob/cb608f5c1e8af4f6fe68bc31cb96013308a4003b/apt-pkg/deb/dpkgpm.cc#L1457 > 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. > Confusing, inflexible, doesn't solve underlying problems, causing more problems elsewhere, probably doesn't work as intended and potentially harmful? If maintenance is concern here, why bring more stuff and more dependencies that don't quite work into apt then?
