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
Attachment:
signature.asc
Description: signature