Discussion:
Bug#941937: apt: Unexpected linkage dependency on libsystemd
Add Reply
Andreas Messer
2019-10-07 18:40:02 UTC
Reply
Permalink
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 gpgv 2.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 <none>
ii aptitude 0.8.11-7
ii dpkg-dev 1.19.7
ii gnupg 2.2.12-1+deb10u1
ii powermgmt-base 1.34
ii synaptic 0.84.6

-- no debconf information
--
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51
Julian Andres Klode
2019-10-07 19:30:01 UTC
Reply
Permalink
Control: tag -1 wontfix
Control: severity -1 wishlist
Post by Andreas Messer
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
Adam Borowski
2019-10-08 23:00:02 UTC
Reply
Permalink
Post by Julian Andres Klode
Post by Andreas Messer
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.
Post by Julian Andres Klode
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.
David Kalnischkies
2019-10-09 15:50:01 UTC
Reply
Permalink
Post by Adam Borowski
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.
Post by Adam Borowski
Post by Julian Andres Klode
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
Balint Reczey
2019-10-09 16:30:01 UTC
Reply
Permalink
Hi David,
Post by David Kalnischkies
Post by Adam Borowski
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.
Post by Adam Borowski
Post by Julian Andres Klode
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
Loading...