[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
>>> ======
>>> 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
>>> 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.

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: