Hi,
TLDR: allow packages in Debian and derivatives to install kernel hooks into
/usr/share/kernel instead of using /etc/kernel. In a nutshell, it calls
run-parts like this:
run-parts /etc/kernel/postinst.d /usr/lib/kernel/postinst.d
When Debian packages install files (including kernel maintainer script hooks)
into /etc, they will be marked as a conffile. This has undesirable side-effects
like the file will not be removed upon package removal (unless purged) and if
the user changes the file, then deploying fixes is not straight forward
anymore. This patch allows distributions to to install their kernel hooks into
/usr/share/kernel from where they are then picked up by run-parts. If the admin
wants to either disable or change the hooks, they can do so by placing a file
into /etc/kernel. Files placed in /etc/kernel will override files of the same
name in /usr/share/kernel. This mechanism might be known from how systemd and
related software organizes configuration files in /etc and /usr. The mechanism
is documented in as the UAPI Configuration Files Specification:
https://uapi-group.org/specifications/specs/configuration_files_specification/
This functionality relies on run-parts 5.21 or later. If run-parts is lacking
support, only scripts in /etc/kernel will be considered. It is the
responsibility of packages installing hooks into /usr/share/kernel to also
declare a Depends: debianutils (>= 5.21). The logic I implemented tries hard to
not require this new functionality by checking whether either of the
directories exists and is empty or not. Only when both directories exist and
contain files is run-parts executed with both directories as arguments. Since
this will fail if run-parts is too old, a check is added to test the run-parts
version. Unfortunately the run-parts --version output is not quite machine
readable, so I agreed with the debianutils maintainer to use the --help output
instead. Should run-parts be too old, then only the /etc directory is passed
to run-parts and thus files in /usr will be ignored. It is the responsibility
of distribution packages to declare a dependency on debianutils (>= 5.21) once
they start placing files into /usr/share/kernel.
The if/else tree can be considerably simplified, once this new functionality
of run-parts 5.21 has been in a few Debian stable releases. Until then, I think
it makes sense to try and be conservative and try to execute run-parts with
only a single directory if possible.
What do you think?
Thanks!
cheers, josch
Johannes Schauer Marin Rodrigues (1):
scripts/package/builddeb: allow hooks also in /usr/share/kernel
scripts/package/builddeb | 39 ++++++++++++++++++++++++++++++++++-----
1 file changed, 34 insertions(+), 5 deletions(-)
--
2.39.2
