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
--==============87763497621542099=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmefSfkACgkQ8sulx4+9 g+Exqw/+Jz/i1Gi2pi07dqzlYwnC2xckZkSSl9jyDFc72LV57bYcMGOiMPQqoLSH p2pqCTVAlTiRR5p3iZiODeMJDtHNPfnUKv19k0yjSBBhy8diKwNaZguiBofsR1Tw DXRv76x+w3HoKiQdxXC+1P+gMu+GSUPxTkUyXYuWNjyioDHW1+NaNTNr8BjDh4fX y8WzocMHMI8Gh7brVrQIKWgd3bbsLflGhgpINYjEEmL5QZUQEZcwz3n1b2UX7Jf4 XiP5R6iFo3BzchJtuc1FWkm0hfEzYKGrzALJeITqD3h6nKn1TUNbNczTHL0Sh1zJ 0DeijodzIYTE2bHaAxBLOrfpAmmzZZxW3uAEbyNjdiuyy5hTHkcOFjRuJrVRiefw rrptDV5kuJ+c5KOhcBCm4JuymRxtqsLjhH3Zp03O0pIiG0iWGFDu4qGUW1IWDyPa JRG0nud8hyupUGUpODTkaYovsf76RQ0BCLIPotloMqrQUwaI0NYqnKVp/rbtyH+x TFIAvTRvRqc+vB6OKHMeVg4PzsoGNhdeeuNlTN6L2OE1a5HaM8GhC5ipgX2mFWcG Gth5zZAJlMp8DEdmZsj/ufk4zokZd8T1/iDyqZYa8ROke285g3bPvqsdj2OpoKeR NXdZ+DQQYkqRCnhV34kVuTDCO/CP3qKbmYxQEf7Jmjn2me+BKWo=
=INoS
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.bugs.dist

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
--==============89960161906987502=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmfqXzIACgkQ8sulx4+9 g+HaLRAAohdrYp1gEjgeB3fmfFd/ahhgO3P20SFM1PEs0SU4tRYCTHVZSY01rgTy 8tYRd8L6Y4oBH28GYJUgbXPaK8dibsMYexeAW04sF7Bge/QSgO/feMf4lX/7EA/q WkvFzdrf2jWFaQVofWyVwLw+qBBeQhYVvMxdhvWDwODgX6NByZrKFlkK1kPAjzqr SyqaX84PkK+wi8C0t0l5emlNe9Ajjn6a/g+Ul+DM2vrz3MHCeAFy0ilh/p2Q3tE/ m6vyn/LakrgF+k/IBV/n6pv2fqkhPPiefQf2QRaGYtRDyy52r2Yxt+U4gUNxFmX4 wSZNxdJgjIinBau2uf5t3pAFbOE3jlGSQt1mof+rVljXyCBnaxnbyTv7vwKNyDhK Toh/ls5trcl6HqUHkUD3ah6iQ4FVpd/van5P8W9Xdshx70HA0ircyEVldSSBo/0P dX4NcawwhlrcNAyXdRhvaZfRF2CGw4TKm3s6Dyz2TiVlcG4aY4JEXrgo3zIyU6Tv eT4CxV49AlTKTu55vlSzikOKxIlZttW5oIttGIM6UztySYAk14Ta+mAPSfSSEJDe 8Fy/YRNaLLTmIXTOydnbZg8Z6zLp576Jbe1x/MIIkZ+ArnmNpIvAM2zPkfCeEUFL ZTga+Aj88pv+EaJxgoVUcE8BtgMMZMfKq5Kbbzt3GEe1UYo9Bbg=
=aih+
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format...

Your message dated Thu, 29 May 2025 17:00:12 +0000
with message-id <E1uKgc0-00642s-5S@fasolo.debian.org>
and subject line Bug#1101733: fixed in linux 6.15-1~exp1
has caused the Debian Bug report #1101733,
regarding debian/templates/image.*.in: allow maint scripts in /usr/share/kernel/*.d
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


--
1101733: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101733
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

Received: (at submit) by bugs.debian.org; 31 Mar 2025 09:24:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.4.6-bugs.debian.org_2005_01_02
(2021-04-09) on buxtehude.debian.org
X-Spam-Level:
X-Spam-Status: No, score=-123.4 required=4.0 tests=BAYES_00,
BODY_INCLUDES_PACKAGE,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,DKIM_VALID_EF,FROMDEVELOPER,HAS_PACKAGE,MD5_SHA1_SUM,
PGPSIGNATURE,SPF_HELO_NONE,SPF_NONE,UNPARSEABLE_RELAY,
USER_IN_DKIM_WELCOMELIST,USER_IN_DKIM_WHITELIST autolearn=ham
autolearn_force=no version=3.4.6-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 19; hammy, 150; neutral, 257; spammy,
0. spammytokens:
hammytokens:0.000-+--Hx-spam-relays-external:sk:stravin,
0.000-+--H*RT:sk:stravin, 0.000-+--Hx-spam-relays-external:311,
0.000-+--H*RT:311, 0.000-+--H*RT:108
Return-path: <josch@debian.org>
Received

This is a multi-part message in MIME format...

Your message dated Sat, 07 Jun 2025 18:00:11 +0000
with message-id <E1uNxpz-001pxz-D3@fasolo.debian.org>
and subject line Bug#1101733: fixed in linux 6.12.32-1
has caused the Debian Bug report #1101733,
regarding debian/templates/image.*.in: allow maint scripts in /usr/share/kernel/*.d
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


--
1101733: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101733
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

Received: (at submit) by bugs.debian.org; 31 Mar 2025 09:24:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.4.6-bugs.debian.org_2005_01_02
(2021-04-09) on buxtehude.debian.org
X-Spam-Level:
X-Spam-Status: No, score=-123.4 required=4.0 tests=BAYES_00,
BODY_INCLUDES_PACKAGE,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,DKIM_VALID_EF,FROMDEVELOPER,HAS_PACKAGE,MD5_SHA1_SUM,
PGPSIGNATURE,SPF_HELO_NONE,SPF_NONE,UNPARSEABLE_RELAY,
USER_IN_DKIM_WELCOMELIST,USER_IN_DKIM_WHITELIST autolearn=ham
autolearn_force=no version=3.4.6-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 19; hammy, 150; neutral, 257; spammy,
0. spammytokens:
hammytokens:0.000-+--Hx-spam-relays-external:sk:stravin,
0.000-+--H*RT:sk:stravin, 0.000-+--Hx-spam-relays-external:311,
0.000-+--H*RT:311, 0.000-+--H*RT:108
Return-path: <josch@debian.org>
Received