Re: Standardizing use of kernel hook scripts
On Wed, Apr 01 2009, Frans Pop wrote:
> 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=2Some 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 think that there are Debian users who use that option of
make-kpkg, and I have not seen any indication that there usage of that
option has decreased.
> (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.
>>> 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.
I am not subscribed to -kernel, though I would consider myself
as a stake holder.
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.
For example, how is an initramfs creation script supposed to
determine when the package creator wants to use an initrd? When I build
my own kernels, I have stopped using modules (apart from nvidia). I
certainly do not need an initrd -- how does one tell the initrd script
not to trigger for some image packages and not others?
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?
I think that crafting a policy is crucial if we want different
mechanism to create kernel packages all work seamlessly in Debian,
instead of each taking the approach that they are the sole users of the
/etc/kernel/*.d mechanism.
manoj
--
Prosperity makes friends, adversity tries them. Publilius Syrus
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: