Bug#941937: apt: Unexpected linkage dependency on libsystemd
(I guess the last email was the disagree email, and this one is the positive one, idk, I just missed those two points) On Fri, Jun 05, 2020 at 04:15:07PM +0200, Adam Borowski wrote: > On Fri, Jun 05, 2020 at 10:34:47AM +0200, Julian Andres Klode wrote: > > On Fri, Jun 05, 2020 at 04:34:23AM +0300, Aleksey Tulinov wrote: > Why even a warning? All the inhibit thing does is to prevent the admin from > doing something stupid (rebooting during an upgrade), and even that has > non-fatal results. Debian had no inhibit at all for decades and the sky > wasn't falling -- so it's a purely facultative option. If the system has > been booted using systemd and systemd is in an usable state (no changing > archs, etc) then inhibit will work -- otherwise, that particular handhold > won't be there. I agree. The thing is, we silently ignore failures to inhibit. This means it works fine on non-systemd systems - as it always did. Adding a warning on systems where it should work (stat(/run/systemd/system) == 0) would make it easy to discover regressions, but it's ultimately not super useful, as people won't read it anyway, especially if it's a background process doing this. > > > This is a best effort thing, there's nothing sensible we can do if it > > fails, except for logging a warning, and that does not help a lot. We > > don't want to issue an error obviously because you still want to be able > > to upgrade the system if your dbus is down or stuff. > > Just silently ignore a failure to inhibit. That's what we do right now. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#941937: apt: Unexpected linkage dependency on libsystemd
On Fri, Jun 05, 2020 at 04:15:07PM +0200, Adam Borowski wrote: > On Fri, Jun 05, 2020 at 10:34:47AM +0200, Julian Andres Klode wrote: > > On Fri, Jun 05, 2020 at 04:34:23AM +0300, Aleksey Tulinov wrote: > > > systemd-inhibit --what="shutdown" --mode="block" /internal/path/to/dpkg $@ > > > > Let's try this again: We run dpkg multiple times. We need to run dpkg > > up to a safe point where you can shutdown without ending with a broken > > system you possibly can't recover from. > > dpkg already does that. In fact, it uses really slow methods to increase > chance of survival on ancient unsafe filesystems like ext2. If dpkg being > interrupted leaves a system unrecoverable, that would be a severity:critical > bug and a fat regression over what we enjoyed for decades. > > And that's for interrupting dpkg inside one invocation. Between invocations > the committed state is even more consistent, and fsynced to the disk. > That's completely irrelevant. We cannot reboot in a state with unconfigured packages, because apt cannot recover from that. I've broken plenty of systems interrupting apt and then had to dpkg -i /var/cache/apt/archives/*.deb until apt got to a point where it was working again. > > > > and let it be something else in other distros? > > > > What are you on about now? Other distros can make their own choices, > > and build apt without the systemd dependency. > > This is bug tracker for _Debian_ not Ubuntu. Ubuntu is systemd-only, > Debian is not. And APT works fine without systemd. You can have libsystemd0 installed or that libelogind thing without having to run systemd. Whoa, crazy, right? If you want to switch your init system, do it from a live disc, not on a live system. > > > > And if you want something that works equally well > > > to systemd's inhibit, why not use systemd-inhibit in the first place? > > > > We are using the library that was designed for that purpose. You don't > > call binaries you've got a library for. That would be a hack. > > Except that the library is fragile, thus shouldn't be used this way from a > vital component of the system without being able to handle failures. > > Solutions include: > * dlopen()ing the library > * executing a binary > -- of which, the latter provides more isolation thus is safer. Both are complicated, fragile, hacks. The first one we did before with udev, and it ended up being broken for multiple years. The latter you need to come up with an RPC protocol to have the forked binary fork the individual dpkgs. Neither are solutions. > > I mean, I guess I could just create a filter and archive emails to > > the bug automatically, but this still means everyone else gets > > trolled. > > Would you accept a NMU fixing this, then? A person uploading such an NMU should have his upload rights revoked. We could move both systemd users (I guess) to use libglib2.0's gdbus library. We have no interest in doing this at the moment, as we don't need it and libsystemd0 pulls in less than libglib2.0 does on almost all systems. Since this is affecting every system, we can't just keep growing the set of packages installed by default. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#941937: apt: Unexpected linkage dependency on libsystemd
On Fri, Jun 05, 2020 at 10:34:47AM +0200, Julian Andres Klode wrote: > On Fri, Jun 05, 2020 at 04:34:23AM +0300, Aleksey Tulinov wrote: > > systemd-inhibit --what="shutdown" --mode="block" /internal/path/to/dpkg $@ > > Let's try this again: We run dpkg multiple times. We need to run dpkg > up to a safe point where you can shutdown without ending with a broken > system you possibly can't recover from. dpkg already does that. In fact, it uses really slow methods to increase chance of survival on ancient unsafe filesystems like ext2. If dpkg being interrupted leaves a system unrecoverable, that would be a severity:critical bug and a fat regression over what we enjoyed for decades. And that's for interrupting dpkg inside one invocation. Between invocations the committed state is even more consistent, and fsynced to the disk. > Stop telling us what to do, you don't have a clue. > > dpkg being invoked as a process is a hack, a workaround because dpkg's > library is unusable, it's not a design decision. > in fact ... it's a lot of issues. There are a lot of design breakages in dpkg, but this isn't one. I believe I did enough reinventing of dpkg to have a clue. > > and let it be something else in other distros? > > What are you on about now? Other distros can make their own choices, > and build apt without the systemd dependency. This is bug tracker for _Debian_ not Ubuntu. Ubuntu is systemd-only, Debian is not. > > And if you want something that works equally well > > to systemd's inhibit, why not use systemd-inhibit in the first place? > > We are using the library that was designed for that purpose. You don't > call binaries you've got a library for. That would be a hack. Except that the library is fragile, thus shouldn't be used this way from a vital component of the system without being able to handle failures. Solutions include: * dlopen()ing the library * executing a binary -- of which, the latter provides more isolation thus is safer. > > 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` > > Don't talk about stuff you don't know anything about. It does not help > you. What we do with the fd is what we're supposed to do - keep it open > until we are done. Closing the fd is what releases the inhibitor. As long as dbus and logind survive. Try eg. crossgrading architectures to see them fail completely -- which is not a problem with other tools. > Right, let's just fail if we can't inhibit, because we don't support > non-systemd systems. Winner! That's Ubuntu, not Debian. The GR was clear -- option F which would have dropped support for non-systemd has been rejected. We ship multiple other rc systems: sysv-rc, openrc, runit, container-specific tools, etc. And we even financially sponsor development of non-systemd stuff. Systemd doesn't even _work_ on some popular containers, and it doesn't work either on some non-obscure setups (like, my personal workstation). This is fine with Debian; you as a core Ubuntu dev are biased towards it, but for me, Ubuntu being systemd-only is a hardship. As qemu fails to properly emulate hardware I work on, I need to use small dingy boxes instead of my fat one just to test if Ubuntu is ok. For this reason, validating $dayjob stuff on Ubuntu done by me is less adequate than it should be. > Sure, I mean we could check if we are actually running on systemd and > then log a warning, but then we also don't work with the libsystemd > shims if they gain support for this, so why bother? Why even a warning? All the inhibit thing does is to prevent the admin from doing something stupid (rebooting during an upgrade), and even that has non-fatal results. Debian had no inhibit at all for decades and the sky wasn't falling -- so it's a purely facultative option. If the system has been booted using systemd and systemd is in an usable state (no changing archs, etc) then inhibit will work -- otherwise, that particular handhold won't be there. > This is a best effort thing, there's nothing sensible we can do if it > fails, except for logging a warning, and that does not help a lot. We > don't want to issue an error obviously because you still want to be able > to upgrade the system if your dbus is down or stuff. Just silently ignore a failure to inhibit. > This bug is open to document our decision, not for people to harass > us. Maybe this was a bad idea and I should have closed and archived > it to avoid it attracting trolls. And hide problems, right? > I mean, I guess I could just create a filter and archive emails to > the bug automatically, but this still means everyone else gets > trolled. Would you accept a NMU fixing this, then? > debian developer - deb.li/jak |
Bug#941937: apt: Unexpected linkage dependency on libsystemd
пт, 5 июн. 2020 г. в 11:34, Julian Andres Klode : > This is a best effort thing, there's nothing sensible we can do if it > fails, except for logging a warning, and that does not help a lot. We > don't want to issue an error obviously because you still want to be able > to upgrade the system if your dbus is down or stuff. > So this was added to prevent dpkg from running if the system is going down, but if the system is going down and dbus isn't up then dpkg is going to yolo anyway and this "works as intended"? Nice. Indeed, this entire discussion is completely pointless. > Stop talking. > > This bug is open to document our decision, not for people to harass > us. Maybe this was a bad idea and I should have closed and archived > it to avoid it attracting trolls. > I thought i was writing to the issue tracker and not to your personal blog, this interface is very confusing. I'm sorry, i didn't mean to violate your privacy.
Bug#941937: apt: Unexpected linkage dependency on libsystemd
On Fri, Jun 05, 2020 at 04:34:23AM +0300, Aleksey Tulinov wrote: > пт, 5 июн. 2020 г. в 00:30, David Kalnischkies : > > > 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 $@ Let's try this again: We run dpkg multiple times. We need to run dpkg up to a safe point where you can shutdown without ending with a broken system you possibly can't recover from. Stop telling us what to do, you don't have a clue. dpkg being invoked as a process is a hack, a workaround because dpkg's library is unusable, it's not a design decision. in fact ... it's a lot of issues. > and let it be something else in other distros? What are you on about now? Other distros can make their own choices, and build apt without the systemd dependency. > > And if you want something that works equally well > to systemd's inhibit, why not use systemd-inhibit in the first place? We are using the library that was designed for that purpose. You don't call binaries you've got a library for. That would be a hack. > 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` Don't talk about stuff you don't know anything about. It does not help you. What we do with the fd is what we're supposed to do - keep it open until we are done. Closing the fd is what releases the inhibitor. > 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. Right, let's just fail if we can't inhibit, because we don't support non-systemd systems. Winner! Sure, I mean we could check if we are actually running on systemd and then log a warning, but then we also don't work with the libsystemd shims if they gain support for this, so why bother? This is a best effort thing, there's nothing sensible we can do if it fails, except for logging a warning, and that does not help a lot. We don't want to issue an error obviously because you still want to be able to upgrade the system if your dbus is down or stuff. > > 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? Stop talking. This bug is open to document our decision, not for people to harass us. Maybe this was a bad idea and I should have closed and archived it to avoid it attracting trolls. I mean, I guess I could just create a filter and archive emails to the bug automatically, but this still means everyone else gets trolled. So, if this trolling continues, I'll probably close the bug and archive it, so replies get rejected. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#941937: apt: Unexpected linkage dependency on libsystemd
пт, 5 июн. 2020 г. в 00:30, David Kalnischkies : > 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 equally well 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?
Bug#941937: apt: Unexpected linkage dependency on libsystemd
On Thu, Jun 04, 2020 at 09:24:22PM +0300, Aleksey Tulinov wrote: > On Wed, 9 Oct 2019 17:36:07 +0200 David Kalnischkies > 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. What you're saying is akin to I'm not a big expert in locking and never will be, but perhaps `flock apt ...` should do the about same thing, and you don't need locking Think a second about what your writing. > > This linking to libsystemd is redundant. If issue is with dpkg leaving > 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 > systemd: The issue is the same we have frontend lock for, but at shutdown. The facility we use is specifically to prevent people from shutting down in a clear and working manner. Of course, once we avoid the need to run dpkg multiple times, it would be nice if dpkg made use of this mechanism itself. > > It would be really nice if this dependency is removed and ideally > underlying issue(s) properly fixed instead of applying band aid here > and there. This _is_ the proper fix for the issue. Now, to put it for your sysvinit poisoned mind, this is somewhat similar to having a K01 script that waits for /var/lib/dpkg/lock-frontend to be released; but - it actually prevents you from shutting down in the first place, rather than just holding up the shutdown. In any case, we have since grown additional places in apt that make use of libsystemd anyway. So, please use Devuan and leave us alone. Thanks! -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#941937: apt: Unexpected linkage dependency on libsystemd
On Thu, Jun 04, 2020 at 09:24:22PM +0300, Aleksey Tulinov wrote: > On Wed, 9 Oct 2019 17:36:07 +0200 David Kalnischkies > 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 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. signature.asc Description: PGP signature
Bug#941937: apt: Unexpected linkage dependency on libsystemd
On Wed, 9 Oct 2019 17:36:07 +0200 David Kalnischkies 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. This linking to libsystemd is redundant. If issue is with dpkg leaving 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 systemd: 1) Doesn't solve any underlying issues; 2) Doesn't solve any issues on systems without systemd; 3) Doesn't solve the issue on systems with systemd installed but not running because in that case there won't be anyone to react on dbus message and inhibit shutdown, so this is not going to work. 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. It would be really nice if this dependency is removed and ideally underlying issue(s) properly fixed instead of applying band aid here and there.
Bug#941937: apt: Unexpected linkage dependency on libsystemd
Hi David, On Wed, Oct 9, 2019 at 6:03 PM David Kalnischkies wrote: > > 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. For the record unattended-upgrades handles inhibition on its own (differently) and did so before libapt added inhibition handling. Cheers, Balint -- Balint Reczey Ubuntu & Debian Developer
Bug#941937: apt: Unexpected linkage dependency on libsystemd
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 signature.asc Description: PGP signature
Bug#941937: apt: Unexpected linkage dependency on libsystemd
On Mon, Oct 07, 2019 at 09:23:01PM +0200, Julian Andres Klode wrote: > On Mon, Oct 07, 2019 at 08:22:33PM +0200, Andreas Messer wrote: > > Would it make sense to use dlopen() to dynamically load libsystemd when > > needed > > and avoid the hard dependency on libsystemd? If systemd is installed, > > libsystemd > > will be available anyways. > > This is too fragile, it broke our udev integration last time for years, hence > we are not using dlopen() anymore. A simple solution is the best solution. > > We have no intention to change anything in the near future. libsystemd is > widely available (or libelogind0 is), and is basically essential, is tiny, > and it's dbus library is the easiest to use. 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 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. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#941937: apt: Unexpected linkage dependency on libsystemd
Control: tag -1 wontfix Control: severity -1 wishlist On Mon, Oct 07, 2019 at 08:22:33PM +0200, Andreas Messer wrote: > Package: apt > Version: 1.8.2 > Severity: normal > > I observed a linkage dependency on libsystemd. This was unexpected for me > since I wouldn't expect a package manager depend on it. A package manager > should > be as lean as possible. > > Having reviewed the code, the only function using libsystemd is used to talk > on dbus > to inhibit system shutdown. Something which will work for systemd only. > > Would it make sense to use dlopen() to dynamically load libsystemd when needed > and avoid the hard dependency on libsystemd? If systemd is installed, > libsystemd > will be available anyways. This is too fragile, it broke our udev integration last time for years, hence we are not using dlopen() anymore. A simple solution is the best solution. We have no intention to change anything in the near future. libsystemd is widely available (or libelogind0 is), and is basically essential, is tiny, and it's dbus library is the easiest to use. 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. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#941937: apt: Unexpected linkage dependency on libsystemd
Package: apt Version: 1.8.2 Severity: normal I observed a linkage dependency on libsystemd. This was unexpected for me since I wouldn't expect a package manager depend on it. A package manager should be as lean as possible. Having reviewed the code, the only function using libsystemd is used to talk on dbus to inhibit system shutdown. Something which will work for systemd only. Would it make sense to use dlopen() to dynamically load libsystemd when needed and avoid the hard dependency on libsystemd? If systemd is installed, libsystemd will be available anyways. -- Package-specific info: -- (no /etc/apt/preferences present) -- -- (/etc/apt/preferences.d/avoid-systemd present, but not submitted) -- -- (/etc/apt/sources.list present, but not submitted) -- -- (/etc/apt/sources.list.d/devuan.list present, but not submitted) -- -- System Information: Debian Release: 10.0 Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages apt depends on: ii adduser 3.118 ii debian-archive-keyring 2019.1 ii gpgv2.2.12-1+deb10u1 ii libapt-pkg5.0 1.8.2 ii libc6 2.28-10 ii libgcc1 1:8.3.0-6 ii libgnutls30 3.6.7-4 ii libseccomp2 2.3.3-4 ii libstdc++6 8.3.0-6 Versions of packages apt recommends: ii ca-certificates 20190110 Versions of packages apt suggests: pn apt-doc ii aptitude0.8.11-7 ii dpkg-dev1.19.7 ii gnupg 2.2.12-1+deb10u1 ii powermgmt-base 1.34 ii synaptic0.84.6 -- no debconf information -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51
