Re: Standardizing use of kernel hook scripts

[Frans Pop <elendil@planet.nl>]

Manoj Srivastava wrote:
> On Wed, Apr 01 2009, Frans Pop wrote:
>> (i.e. is there any reason to _add_ support for it in deb-pkg or in
>> whatever the kernel team is planning)?
> 
>         I think so. If we do standardize on /etc/kernel/*.d directories
>  as the place where kernel packages will look into to run scripts, then
>  the scripts in that location should have a common API. Since we have an
>  installed base, and there is going to be continued support for this
>  feature by the current debian end user kernel packaging tool, we can't
>  just drop the old api and scripts.

Eh, different _existing_ tools already diverge. I agree on the need for a 
common API, or at least ensuring that there is legacy support. (After 
all, that is why I sent my initial mail).
But I see no reason why the "the make-kpkg way" should be elevated to that 
standard API without any discussion.

>         Also, this proposal should go through the vetting of the primary
>  place we make technical policy for Debian, which is the debian-policy
>  mailing list. Since this is going to require interaction between all
>  kinds of packages in providing scripts for kernel package handling, the
>  standards we create for determining when these scripts are triggered,
>  how parameters are passed in, is precesily the kind of thing that
>  policy is created for.

I have no problems with that.

>         Traditionally, you passed --initrd to make-kpkg to trigger the
>  call to initrd; but now that we are thinking of different drivers than
>  make-kpkg, how is this information stored and sent to the script?

Which only worked because initrd generation was/is coded in the postinst 
itself and not in a postinst hookscript.

To be honest, I don't really see why k-p supports hook scripts at all, 
given that it already does everything that's normally needed in the 
regular postinst it generates. For that reason I would guess that the 
number of users that actually use the existing hook script mechanism in 
make-kpkg is very, very low [1].

And that is a completely different model from what the deb-pkg target does 
and what's now being considered by the kernel team. Unifying those 
separate models is always going to be painful.

Cheers,
FJP

[1] Which IMO makes the "legacy" issue somewhat less important than it 
would otherwise be.