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 <david@kalnischkies.de>:
>
> > 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 <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.
> 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
Reply to: