Bill Allombert <ballo...@debian.org> writes:
> But we do: we support debhelper 13.11.4 and debhelper 13.11.6. Even if
> we support a single implementation, we still need to know what is
> expected of it.
Policy already requires a single implementation of quite a lot of tools,
does not specify a version, and does not specify how they do what they do.
Bugs are handled as bugs against the packages that supply those tools, and
what they do, except at a very high level, is opaque to Policy. Examples
include update-rc.d, invoke-rc.d, adduser, and ldconfig, as well as the
obvious example of dpkg (which doesn't really count).
Now, I realize that debhelper feels conceptually different than those, and
I think to some extent it *is* conceptually different. Those are all
tools that do a single thing, whereas debhelper is an infrastructure that
has a lot of implications for how the package is defined and assembled.
It is a big step to go from requiring that all packages use a specific
tool to requiring that packages of a specific type use a particular
packaging framework. That's why I wanted to have a discussion about that
first.
The alternative is to adopt deb-systemd-invoke and deb-systemd-helper as
tools similar to update-rc.d and invoke-rc.d and specify how packages
should call them. This is indeed what I had started doing. But when I
started writing the language for this, it quickly became obvious that
those tools were written for debhelper and debhelper embeds a lot of
information about how to call them. (deb-systemd-invoke, for an obvious
example, has a very minimal man page.)
The invocation added by dh_installsystemd is also not entirely trivial.
Here is an example from wpasupplicant, reformatted a bit to make it more
readable in a mail message (and also note that my system has several
versions of this, so it's clearly under active development):
# Automatically added by dh_installsystemd/13.11.6
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] \
|| [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
# The following line should be removed in trixie or trixie+1
deb-systemd-helper unmask 'wpa_supplicant.service' >/dev/null || true
# was-enabled defaults to true, so new installations run enable.
if deb-systemd-helper --quiet was-enabled 'wpa_supplicant.service'; then
# Enables the unit on first installation, creates new
# symlinks on upgrades if the unit file has changed.
deb-systemd-helper enable 'wpa_supplicant.service' >/dev/null || true
else
# Update the statefile to add new symlinks (if any), which need to be
# cleaned up on purge. Also remove old symlinks.
deb-systemd-helper update-state 'wpa_supplicant.service' >/dev/null || true
fi
fi
# End automatically added section
# Automatically added by dh_installsystemd/13.11.6
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] \
|| [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
if [ -d /run/systemd/system ]; then
systemctl --system daemon-reload >/dev/null || true
if [ -n "$2" ]; then
_dh_action=restart
else
_dh_action=start
fi
deb-systemd-invoke $_dh_action 'wpa_supplicant.service' >/dev/null || true
fi
fi
# End automatically added section
This is postinst, which is the most complex, but prerm and postrm snippets
are also required.
This felt like kind of a lot to put into Policy. There is a line that
apparently won't be needed in the future, there's an update-state concept
that's internal to the tool, and the logic differs based on whether this
is a package upgrade or a new installation. We can put this all into
Policy, but I would just be blindly copying and pasting code from
debhelper, and I'm very dubious that it is going to stay accurate and up
to date (as witnessed by the fact that the existing snippets in Policy for
using update-rc.d and invoke-rc.d do not match what debhelper does and are
likely broken for packages that also include systemd units or packages
that need to care about DPKG_ROOT).
Also, honestly, nearly all packagers think of debhelper as an opaque tool
that everyone uses, and I have a larger concern that this makes Policy
much less useful for a large part of its intended audience than it could
be. Quite a lot of Policy is of the general format "here's a bunch of
complex things you need to do, wait, never mind, just use debhelper, go
see its documentation for the configuration files you should use instead"
and some of the rest of Policy is "here's a bunch of complex things you
need to do but if you follow these instructions instead of using debhelper
your package will be buggy." This is not ideal!
I think there's a lot of appeal of having a thorough specification for
what debhelper is supposed to be doing. It would enable future
competition around better packaging helpers (and I do think debhelper will
not be the last word). But I also want to be realistic about whether
we're really capable of maintaining that specification.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
