[v2,0/1] scripts/package/builddeb: allow hooks also in /usr/share/kernel

Message

Johannes Schauer Marin Rodrigues Nov. 28, 2024, 6:29 a.m. UTC

Hi,

Quoting Masahiro Yamada (2024-11-28 02:38:40)
> Signed-off-by: is required for any kernel patch.

whoops, you see I'm not doing this often. :D Thank you for your
patience.

> However, the added complexities look skeptical to me.

Yes, I struggle to find a good balance between the problem that only recent
versions of run-parts will support this versus trying to be safe and doing the
best we can if things go badly. I think this new version is quite a bit easier
to read.

> If /usr/share/kernel/postinst.d/ exists on the installed system,
> we can assume run-parts>=5.21 exists there.

But what shall we do if it does not? My new patch falls back to only calling
run-parts on the first directory (which will be /etc by default) in an attempt
to not leave the user hanging. The assumption here is, that distros will
probably want to only allow packages placing hooks into /usr once a version
of debianutils with support for this made it into a stable release. This is
still a while off. This means, that for a long while, all the important scripts
will still all be in the familiar path in /etc.

> One more thing, do we need a new env variable
> for the second search path?
>█
> If a user wants to add more search paths for custom hooks,
> they can pass multiple words to KDEB_HOOKDIR.
>█
> export KDEB_HOOKDIR="
> /home/masahiro/etc/kernel
> /etc/kernel
> /usr/local/share/kernel
> /usr/share/kernel
> "
>█
> This is compatible with the current "single path for KDEB_HOOKDIR"
> usage, and flexible enough for the new extension.

Okay. Indeed adding the home directory or /usr/local sounds like valid
use-cases to me. I am a bit hesitant because this forces the paths to
not contain spaces but I guess that's a reasonable requirement to make.

Thank you for your review!

cheers, josch