[Pkg-ltsp-devel] Standardizing use of kernel hook scripts

[Manoj Srivastava]

The following message is a courtesy copy of an article
that has been posted to gmane.linux.debian.devel.kernel as well.

On Tue, Mar 24 2009, Frans Pop wrote:

> Hi all,
>
> I'm not sure whether this discussion should happen here (d-kernel + 
> selected interested parties) or would be better held on d-devel.
> If ppl think it would be better on d-devel, then please let me know and 
> I'll restart it there.

        I think this is best held on -devel, since a wider audience will
 benefit from this.

> INTRO
> =====
> For the past year and more I've been building upstream kernels without 
> using any Debian tools, by just calling the kernel's own 'make deb-pkg' 
> target.
>
> The maintainer scripts for the thus generated kernel image package don't 
> do anything but call hook scripts in /etc/kernel/{pre,post}{inst,rm}.d/.

        The new kernel package maintainer script will expand on
 this. The image packages do call run parts on
    /etc/kernel/{pre,post}{inst,rm}.d/. 
 In additions, the doc, source, and headers packages will call upon
  /etc/kernel/{src,doc,header}_{pre,post}{inst,rm}.d/. 
 This means that hok scripts can take control at any of the maintainer
 script stages, for any of the packages produced by kernel-package.

        In the future, I'll extend this to 
  /etc/kernel/{uml,xen}_{pre,post}{inst,rm}.d/. 

>
> In general the kernel team should be aware that there _are_ other current 
> users of /etc/kernel/ hook scripts.

        Yes. And kernel-package has been doing so for a while, and
 intends to expand the usage.

>
> DEB-PKG PATCHES
> ===============
> My patch series for the upstream kernel contains roughly the following 
> changes:
> - some minor cleanup
> - a fix so that the arm kernel image gets found (use of KBUILD_IMAGE is
>   not completely standard across arches)
> - a way to pass maintainer script parameters to hook scripts (see below)
> - an option to specify a custom package version/revision
> - an option to use a different hook scripts directory from /etc/kernel
>   (I currently use /etc/kernel.custom to avoid my hook scripts to be
>   run when I install an official Debian kernel package)
>
> The last patch provides a general escape, but it would be nice if all 
> Debian kernel packages could use the same hook scripts. (/me dreams)

        Where are these patches?

>
> ISSUES
> ======
> Parameters passed to hook scripts
> ---------------------------------
> Official Debian kernels (at least up to 2.6.26) and make-kpkg based 
> packages pass two parameters:
> - kernel version
> - $realimageloc$kimage-$version (/boot/vmlinuz-<kvers>)

> deb-pkg based packages only pass the kernel-version.
>
> AFAICT ltsp-client hook scripts use neither of these parameters.
>
> New initramfs-tools hook scripts uses the kernel version and includes a 
> hack that tests if $2 is defined to avoid running with pre-squeeze 
> kernels and make-kpkg kernels. Not ideal...
>
> There is legacy here which makes any transition hard. But given the 
> limited existing users of hook scripts I think we can essentially ignore, 
> but it would be good to agree on a standard for the future!

        There are more users of the kernel images than just Debian
 packages; and I do not think we can ignore an installed base without
 reason.

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

> 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?

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

> To conffile or not to conffile
> ------------------------------
> If I'm correct neither initramfs-tools nor ltsp-client currently defines 
> the hook scripts as conffiles. This is both good and bad.
>
> - good: the hook script are removed when the package is removed which
>   avoids the problem that it could get run after removal, but before purge
> - bad: user changes in the scripts get lost on package upgrades
>
> IMO all hook scripts should be conffiles so user changes get preserved. 
> But that means that they need to include a check (existence of main 
> package binary for example) and exit 0 if the package was removed but not 
> purged.

        Anything in /etc is a configuration file, and thus policy
 dictates user changes must be preserved. This is nothing special;
 policy must be followed here, as in any other package.

>
> Allow user to control execution of hook scripts?
> ------------------------------------------------
> There can be various cases where this could be useful. Example would be 
> that it's pretty bad if you have two bootloaders installed (grub and 
> lilo) and both have hook scripts that get run. Some standard mechanism to 
> disable a particular hook script could be useful.
>
> More advanced would be to allow to run hook scripts based on type of build 
> system used: official Debian kernel, make-kpkg, deb-pkg, ...
> This could be done by exporting some envvar that indicates the "source", 
> which would also remove the need for the abovementioned hack i-t uses now 
> (absence of the envvar would mean "legacy").
>
> Some standard for progress output/verbosity?
> --------------------------------------------
> It could be useful to provide some guidelines about when and how to 
> display progress info. As could a general "verbose" option for debugging.
>
> Basic infrastructure
> --------------------
> I think some package will need to provide some basic infrastructure:
> - general config options for all kernel hook scripts (see previous point)
> - install a README explaining the use of kernel hook scripts
> - provide a very early postinst hook that runs 'depmod -a <kvers>'; I'm
>   not sure how else that could be provided
> - possibly be responsible for creating/updating symlinks, although that's
>   always a tough one as you might want symlinks updated for official
>   kernels but not for custom built ones (or use different symlinks for
>   custom kernels); the suggested "source" envvar could help there
> - provide a shell library file with functions to implement some of the
>   ideas mentioned above

        manoj
-- 
I am a man: nothing human is alien to me. Publius Terentius Afer
(Terence)
Manoj Srivastava <srivasta at acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C