Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #85353

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

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

Hi,

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?

Thanks!

cheers, josch

Back to linux.debian.kernel | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

debian/templates/image.*.in: allow maint scripts in /usr/share/kernel/*.d Johannes Schauer Marin Rodrigues <josch@debian.org> - 2025-02-02 11:40 +0100
  Re: debian/templates/image.*.in: allow maint scripts in /usr/share/kernel/*.d Johannes Schauer Marin Rodrigues <josch@debian.org> - 2025-03-31 11:30 +0200
    Bug#1101733: marked as done (debian/templates/image.*.in: allow  maint scripts in /usr/share/kernel/*.d) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2025-05-29 19:10 +0200

csiph-web