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

Groups > linux.debian.kernel > #90311 > unrolled thread

Bug#1121366: Ships /etc/kernel/header_postinst.d instead of /etc/kernel/headers_postinst.d

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1121366: Ships /etc/kernel/header_postinst.d instead of /etc/kernel/headers_postinst.d Andras Korn <korn-debbugs@elan.rulez.org> - 2025-11-27 15:10 +0100
    Bug#1121366: Ships /etc/kernel/header_postinst.d instead of /etc/kernel/headers_postinst.d Ben Hutchings <benh@debian.org> - 2025-11-27 15:50 +0100
      Bug#1121366: Ships /etc/kernel/header_postinst.d instead of /etc/kernel/headers_postinst.d Andras Korn <korn-debbugs@elan.rulez.org> - 2025-11-28 10:40 +0100

#90311 — Bug#1121366: Ships /etc/kernel/header_postinst.d instead of /etc/kernel/headers_postinst.d

On Thu, Nov 27, 2025 at 12:23:39PM +0100, Ben Hutchings wrote:

Hi,

> On Thu, 2025-11-27 at 00:56 +0100, Andreas Beckmann wrote:
> > On 11/25/25 11:38, Andras Korn wrote:
> > > Package: dkms
> > > Version: 3.2.2-1
> > 
> > > dkms ships a /etc/kernel/header_postinst.d/dkms file, which I suppose is expected to run when the linux-headers postinst scripts call:
> > > 
> > > linux-run-hooks headers postinst $version -- "$@"
> > > 
> > > However, linux-run-hooks doesn't use /etc/kernel/header_postinst.d, only /etc/kernel/headers_postinst.d, so the shipped /etc/kernel/header_postinst.d/dkms is never run.
> > > 
> > > (I verified this by adding --verbose --debug to the run-parts invocation in linux-run-hooks.)
> > 
> > This is an uncommunicated (maybe even unintended) path change on the 
> > src:linux side. Older kernels had this in linux-headers-*.postinst:
> [...]
> 
> This was an unintended change when I reimplemented hook handling in
> linux-run-hooks (in linux-base).  I just didn't notice that the
> directory prefix was previously "header_" and not "headers_" (like the
> package names).
> 
> Since nothing appears to install a hook in the new directories
> (/{etc,usr/share}/kernel/headers_postinst.d) yet, I will change this
> back rather than trying to support both.

I also found no package other than dkms install anything there, and dkms's
script hasn't actually run all this time with apparently nobody noticing
(because the same script is shipped in install.d as well).

I think it would be better to keep the name of
/etc/kernel/headers_postinst.d consistent with the -headers in the package
names, rather than modify linux-run-hooks to use the previous,
inconsistently-named directory.

Rationale: principle of least surprise. You don't know how many custom
setups that created /etc/kernel/headers_postinst.d/ (because people found
out that's what linux-run-hooks used) you'd be breaking by changing it.
Probably not many (I know of a total of 3 :), but I don't think there is a
compelling reason to do it.

If the dkms script shipped in /etc/kernel/header_postinst.d is not needed,
the dkms package can just drop it.

Summary: making a change risks breaking existing systems that depend on the
existing behaviour without any obvious benefit; not changing linux-run-hooks
carries no such risk.

Just my 2 cents.

András

-- 
            A bug is a feature that didn't make it into the manual.

[toc] | [next] | [standalone]

#90312

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

On Thu, 2025-11-27 at 14:58 +0100, Andras Korn wrote:
> On Thu, Nov 27, 2025 at 12:23:39PM +0100, Ben Hutchings wrote:
> 
> Hi,
> 
> > On Thu, 2025-11-27 at 00:56 +0100, Andreas Beckmann wrote:
> > > On 11/25/25 11:38, Andras Korn wrote:
> > > > Package: dkms
> > > > Version: 3.2.2-1
> > > 
> > > > dkms ships a /etc/kernel/header_postinst.d/dkms file, which I suppose is expected to run when the linux-headers postinst scripts call:
> > > > 
> > > > linux-run-hooks headers postinst $version -- "$@"
> > > > 
> > > > However, linux-run-hooks doesn't use /etc/kernel/header_postinst.d, only /etc/kernel/headers_postinst.d, so the shipped /etc/kernel/header_postinst.d/dkms is never run.
> > > > 
> > > > (I verified this by adding --verbose --debug to the run-parts invocation in linux-run-hooks.)
> > > 
> > > This is an uncommunicated (maybe even unintended) path change on the 
> > > src:linux side. Older kernels had this in linux-headers-*.postinst:
> > [...]
> > 
> > This was an unintended change when I reimplemented hook handling in
> > linux-run-hooks (in linux-base).  I just didn't notice that the
> > directory prefix was previously "header_" and not "headers_" (like the
> > package names).
> > 
> > Since nothing appears to install a hook in the new directories
> > (/{etc,usr/share}/kernel/headers_postinst.d) yet, I will change this
> > back rather than trying to support both.
> 
> I also found no package other than dkms install anything there, and dkms's
> script hasn't actually run all this time with apparently nobody noticing
> (because the same script is shipped in install.d as well).
> 
> I think it would be better to keep the name of
> /etc/kernel/headers_postinst.d consistent with the -headers in the package
> names, rather than modify linux-run-hooks to use the previous,
> inconsistently-named directory.
>
> Rationale: principle of least surprise. You don't know how many custom
> setups that created /etc/kernel/headers_postinst.d/ (because people found
> out that's what linux-run-hooks used) you'd be breaking by changing it.
> Probably not many (I know of a total of 3 :), but I don't think there is a
> compelling reason to do it.

My rationale:

- The old directory name was supported for 15 years and in 7 stable
releases, so many local packages and scripts may depend on it.  We must
not stop supporting it without a transition plan.

- The new directory name has been supported for 6 months, and it has
been in a stable release for 3.5 months.  Reverting to the old name
post-release is not great, but it will cause less breakage.

> If the dkms script shipped in /etc/kernel/header_postinst.d is not needed,
> the dkms package can just drop it.

Currently linux-headers-* packages depend on the corresponding linux-
image-* packages, but in future that will stop being the case.  So in
some use cases that hook script will be important again.

> Summary: making a change risks breaking existing systems that depend on the
> existing behaviour without any obvious benefit; not changing linux-run-hooks
> carries no such risk.

I think you have it backwards.

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams

[toc] | [prev] | [next] | [standalone]

#90317

On Thu, Nov 27, 2025 at 03:42:10PM +0100, Ben Hutchings wrote:

Hi,

> > > Since nothing appears to install a hook in the new directories
> > > (/{etc,usr/share}/kernel/headers_postinst.d) yet, I will change this
> > > back rather than trying to support both.
> > 
> > I also found no package other than dkms install anything there, and dkms's
> > script hasn't actually run all this time with apparently nobody noticing
> > (because the same script is shipped in install.d as well).
> > 
> > I think it would be better to keep the name of
> > /etc/kernel/headers_postinst.d consistent with the -headers in the package
> > names, rather than modify linux-run-hooks to use the previous,
> > inconsistently-named directory.
> >
> > Rationale: principle of least surprise. You don't know how many custom
> > setups that created /etc/kernel/headers_postinst.d/ (because people found
> > out that's what linux-run-hooks used) you'd be breaking by changing it.
> > Probably not many (I know of a total of 3 :), but I don't think there is a
> > compelling reason to do it.
> 
> My rationale:
> 
> - The old directory name was supported for 15 years and in 7 stable
> releases, so many local packages and scripts may depend on it.  We must
> not stop supporting it without a transition plan.

OK, fair enough. I had no idea what the timeline was.

András

-- 
If I'm ever on life support, unplug me, then plug me back in. See if that works.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web