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

[Frans Pop]

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.

Sorry if any of this has already been discussed or documented. I must 
admit I've not looked very hard.

Cheers,
FJP

(I've subscribed to d-kernel for this discussion but don't mind CCs in 
this case.)


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

Current official Debian kernels (at least up to 2.6.26) also call any 
scripts there and so do kernel packages built using make-kpkg.

I've seen that the new squeeze version of initramfs-tools now installs 
hook scripts in those dirs [1]. I think the kernel team is planning to 
switch to a general use of the hook scripts for squeeze.

A grep through the lintian lab showed ltsp-client as the only other 
package that installs hook scripts there.

For my kernel testing I've been using some patches for the deb-pkg target 
which I'd now like to push upstream. While I was finalizing them, I ran 
into some issues I'd like to discuss with you.

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

[1] Although I did not see it mentioned in the changelog.

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)

Note that none of my patches affect Debian kernel builds as they don't use 
the deb-pkg target.


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!

Is anything other than the kernel version really needed?

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="$@"

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.

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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-ltsp-devel/attachments/20090324/9bb6e824/attachment.sig>