You are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 Re: Devuan » Why apt still links to libsystemd0? » 2020-06-05 17:17:46
bgstack15 wrote:would you know any of the motivations of the apt maintainers who made the choice to link apt to libsystemd0?
No but I would hazard a guess that it is related to the systemd timers now supplied with the package (or perhaps the new sandboxing feature).
They are attempting (not necessarily successfully) to prevent shutdowns/reboots while package manager is running, but that code depends on systemd-logind (or maybe elogind) and doesn't work if, for example, dbus isn't running or something else went wrong. Also i don't know how elogind is going to prevent shutdown/reboot if init system isn't systemd.
The code is here: https://github.com/Debian/apt/blob/cb60 … l.cc#L3444
Another thing they do with systemd is that they track if package manager was invoked in interactive mode/shell or not and include that info into HTTP requests to repo servers. That code is also completely depends on systemd and won't work if you are not running systemd.
https://github.com/Debian/apt/blob/cb60 … tp.cc#L981
Besides that i didn't find any more systemd call in apt.
#2 Re: Devuan » Why apt still links to libsystemd0? » 2020-06-04 16:04:12
Nice. Thank you.
#3 Re: Devuan » Why apt still links to libsystemd0? » 2020-06-04 15:38:21
I dont think there is any way of getting around this as devuan is a fork of debian. I believe it would require a rewrite of the code and a massive downgrade of binaries in the repos.
No, it appears to be just a matter of recompiling apt with `HAVE_SYSTEMD` unset. It is unset when systemd isn't present. I have compiled apt from source code on Devuan (Beowulf) and apt doesn't link to libsystemd0 anymore.
You can try it yourself, source code is here: https://github.com/Debian/apt
You will need `triehash` somewhere in your path, utility itself is here: https://github.com/julian-klode/triehash, then `ln -sf /path/triehash.pl /otherpath/bin/triehash` and `/otherpath/bin` has to be in $PATH so cmake can see it when configuring apt build. The rest of the packages needed for build can be installed from Devuan repos.
#4 Re: Devuan » Why apt still links to libsystemd0? » 2020-06-04 15:10:48
It's installed by libelogind0.
$ ldd $(which apt) | grep -i systemd
$ dpkg -S /usr/lib/x86_64-linux-gnu/libsystemd.so.0#5 Devuan » Why apt still links to libsystemd0? » 2020-06-04 14:16:31
- criminalscum
- Replies: 18
Hi.
So i wanted to look into apt source code to see why it links to libsystemd0 at runtime instead of having an option to detect systemd presence at compile time. I mean, it should't matter if it's detected at runtime or compile time, if systemd absence is detected at runtime, then it can't use it anyway, right? So when we're compiling apt we should be able to tell it beforehand that systemd isn't going to be there. This "runtime detection" of systemd to me seemed sketchy anyway.
To my surprise i've found define called `HAVE_SYSTEMD` already present in source code and since i don't have systemd installed on my system, after i compiled apt from source, apt-get doesn't link to libsystemd0 anymore.
I'm just asking, i'm not pushing anyone to make any changes, i just want to know why is it so, okay? From what i'm seeing in Git log, this define was added in 2019.
Does it link to libsystemd0 because apt in Devuan is build from older source code or is that because apt in Devuan is built on Debian that has systemd? Any plans to rebuild it w/o libsystemd0? This file seems to be installed by libelogind0 and i can't remove libelogind0 without removing apt.
I mean, i probably can rebuild it from source and install instead of upstream apt, and i probably should do that at some point, but replacing apt with custom build doesn't sound as a safe option to me, so i wanted to ask first.
Any ideas?
Pages: 1
Board footer
