Re: Standardizing use of kernel hook scripts

[Frans Pop <elendil@planet.nl>]

(dropping ltsp as the list is moderated)

Manoj Srivastava wrote:
>> My patch series for the upstream kernel contains roughly the following
>> changes:
[...]
>         Where are these patches?

Only just submitted:
   http://marc.info/?l=linux-kbuild&m=123861445626856&w=2

maks has also submitted a set of patches:
   http://marc.info/?l=linux-kbuild&m=123851278623264&w=2
Some discussion on those:
   http://marc.info/?l=linux-kbuild&m=123860208704620&w=2

>> ISSUES
>> ======
>> Parameters passed to hook scripts
>> ---------------------------------
>> Is anything other than the kernel version really needed?
> 
>         Yes, since in the old days the image location could be changed,
>  by passing a parameter to make-kpkg. I think this feature is used,
>  since it was put into kernel-package by request.

But is anyone still using it? Is there any current reason to support it
(i.e. is there any reason to _add_ support for it in deb-pkg or in whatever
the kernel team is planning)?
 
>> Maintainer script parameters
>> ----------------------------
>> Currently maintainer script parameters are not passed on to the hook
>> scripts, but IMO they could be very useful, for example: a bootloader
>> update only needs to be run on package removal, but not on purge.
>>
>> Given the previous point I think adding them to the parameters passed to
>> the hook scripts is not a good option. I therefore propose to instead
>> export them in a standard environment parameter. Proposal:
>> export DEB_MAINT_PARAMS="$@"
> 
>         Hmm. That would mean that the first argument is the name of the
>  script, then?

No. $@ starts at $1, not at $0.

In the hook scripts I currently use I do:
version=$1
set -- $DEB_MAINT_PARAMS

>> Execution order of hook scripts
>> -------------------------------
>> Both initramfs-tools and ltsp-client currently just dump a script in the
>> hook dirs without any naming convention. If many packages were to do
>> that, chaos would be a guaranteed result.
>>
>> IMO scripts should have standardized names starting with numbers to
>> regulate execution order. Ranges should be reserved, for example:
>> - early scripts 00-19
>> - initrd generation 30-49
>> - bootloader update 50-69
>> - late scripts 80-99
>>
>> Use of new numbers by packages should probably be coordinated by the
>> kernel team.
> 
>         If this were to become policy, I would say _all_ stakeholders
>  should be involved, not just the official kernel packages, and that
>  means not shutting out end users who compile their own kernel image
>  debs.

Agreed. That's why I said "coordinated" and not "mandated".
However, IMO it's probably not unreasonable to expect stakeholders to be
subscribed to d-kernel.