On Wed, Oct 09, 2019 at 12:53:45AM +0200, Adam Borowski wrote: > It's not about not being available in normal use, it's because switching the > library's implementation is fragile -- especially if systemd's prerm fails > which it's notorious to. This will make apt fail, and apt happens to be the > very package supposed to fix such a problem. I think systemd has to many fingers in too many areas to switch it out at runtime. But I also think you and everyone else reading this bugreport knows that better than I do. That might be unfortunate, but as a user is unlikely to change from and to it a lot it seems like a waste to optimize for potential problems in "unrelated" packages (if we called every package with a failing maintainer script related to apt because it makes apt fail, apt would be related to the entire archive). APT is also not "the very package supposed to fix such a problem". The entire program family is supposed to start from a consistent state and end in a consistent state. Some tools like apt might have a --fix-broken mode which tries to help if it is really easy, but the only tool which can help you for real if you deal with major breakage is dpkg: That not only knows what a maintainer script is (apt doesn't) – it is also essential, so it [normally] works even in inconsistent states. > > I expect that apt will eventually switch to using libglib's dbus support, > > once we implement a daemon, but that's a bit off, and that stuff might live > > in a separate binary to not pull in libglib on systems that don't need a > > daemon. > > Would you accept a patch to move the inhibit function to a small separate > binary? That'd be a very simple solution. The Inhibit() is implemented in libapt so that shutdown is inhibited for all libapt-based tools from aptitude to unattended-upgrades – and so they all gain this linkage via libapt. You can disable it at runtime by setting DPkg::Inhibit-Shutdown to false via config/option. That still requires that the linker can find something to load, but that is a given in a consistent state and in a state so broken that the linker can't, no libapt-based tool can be of much help anyhow. So, I am not sure what a small separate binary would give us… 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) … Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature