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 <quote> equally well <end quote>
> > > 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
Reply to: