Re: Standardizing use of kernel hook scripts
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 .
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.
 Which IMO makes the "legacy" issue somewhat less important than it
would otherwise be.