Debian Bug report logs - #1101733
debian/templates/image.*.in: allow maint scripts in /usr/share/kernel/*.d

Reply or subscribe to this bug.

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer Marin Rodrigues <josch@debian.org>

To: debian-kernel@lists.debian.org

Cc: submit@bugs.debian.org

Subject: Re: debian/templates/image.*.in: allow maint scripts in /usr/share/kernel/*.d

Date: Mon, 31 Mar 2025 11:24:06 +0200

[Message part 1 (text/plain, inline)]

Package: linux
Version: 6.12.21-1
Severity: normal

Hello kernel team,

my last mail to debian-kernel list eight weeks ago has no replies. I'm sorry if
I have missed further discussions on this topic elsewhere. As upstream linux
6.14 (details below) was released last week, I'm moving this email thread to a
bug in the BTS so that it does not get lost. Here my original mail with a
summary of the situation:

Quoting Johannes Schauer Marin Rodrigues (2025-02-02 11:33:34)
> in an attempt to not step on anybody's foot again, let me try to use the
> mailinglist this time to discuss this topic. This is a follow up of this MR
> which is not ideal because it does in shell what I think should be part of
> run-parts from debianutils:
> 
> https://salsa.debian.org/kernel-team/linux/-/merge_requests/1259
> 
> as well as this MR which is better because it uses functionality available in
> debianutils since 5.21:
> 
> https://salsa.debian.org/kernel-team/linux/-/merge_requests/1259
> 
> Reading hooks from /usr/share/kernel is part of torvalds/linux.git since
> ac2c30f98f28a6606af89ce44bff77af5d558fe8 and I'd like to propose again to also
> add this functionality to the Debian kernel packaging.
> 
> The transition plan would be to add support for reading /usr/share/kernel in
> addition to /etc/kernel in Trixie but forbid packages from relying on this
> interface (i.e. they are not allowed to ship files in /usr/share/kernel) for
> Trixie. This will allow one to backport packages from Forky to Trixie once
> Trixie is released. Starting with Forky, packages can rely on the kernel
> respecting hooks in /usr/share/kernel. To make this even safer, packages could
> still be forbidden from using this interface in Forky and only allowed to use
> it in Duke. In any case, I think the first step is for the kernel packaging to
> handle /usr/share/kernel.
> 
> The idea behind this is to introduce a mechanism for packages to ship their
> hook scripts in /usr and allow the administrator to disable or override them in
> /etc. This mechanism is documented here:
> https://uapi-group.org/specifications/specs/configuration_files_specification/
> 
> Shipping content in /etc instead of /usr is problematic for packages because
> package upgrades become a hassle in case the user changed the file in /etc. It
> is not anymore easy for packages to change or delete a maintainer script
> snippet without involving writing their own maintainer script magic. Other
> parts of Debian are also moving to the pattern of: vendor ships files in /usr
> and admin can override them in /etc if necessary. This change allows this for
> the kernel maintainer script snippets as well.
> 
> Enabling this in the Debian linux kernel packaging would require to:
> 
>  - add a Depends on debianutils (>= 5.21)
>  - call run-parts with /usr/share/kernel/... in addition to /etc/kernel/...
>    maintainer scripts
> 
> Since run-parts will throw an error if either of the directories is passed does
> not exist, either the linux-image-* package could ship these (empty)
> directories itself, or maintainer scripts could call run-parts with different
> directories depending on whether /usr/share/kernel/... or /etc/kernel/...
> directories exist or not.
> 
> What do you think? What would you like me to do/provide next to move this topic
> forward?

The latest upstream release of linux 6.14 now includes commit
ac2c30f98f28a6606af89ce44bff77af5d558fe8:

https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ac2c30f98f28a6606af89ce44bff77af5d558fe8

This means, that starting with linux 6.14, the builddeb packaging will look for
kernel hooks in /usr/share/kernel as well in addition to /etc/kernel. As a
result, packages in Debian derivatives or in 3rd party repositories might now
start placing their hooks into /usr/share/kernel instead. If users build
that software on their Debian installations or install these packages on their
Debian boxes, they will fail to work with the Debian linux packaging because
it only looks for hooks in /etc/kernel right now.

In https://salsa.debian.org/kernel-team/linux/-/merge_requests/1159 Bastian
Blank correctly pointed out that the hook mechanism is an unversioned
interface. This is why I brought up above argument. Since upstream linux Debian
packaging now supports /usr/share/kernel, the Debian kernel will stop to work
with packages that assume this interface to work.

I think it would make sense if the kernel package we ship with Trixie supports
that interface as people will start using /usr/share/kernel and they might
expect the kernel of their Debian stable box to support this. Doing this would
also mean that packages in Forky can start relying on this interface even
though it is unversioned because I guess we can assume that their kernel is at
least the version from Debian stable (Trixie)?

Please tell me if you would like to see patches from me that implement this.
Adding support for this is not very hard because run-parts in Trixie supports
multiple directories.

Thanks!

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.