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 [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.
Reply to: