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