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

[maximilian attems]

On Wed, 25 Mar 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.

think this is right place, we could/should add linux-kbuild too.
 
> Sorry if any of this has already been discussed or documented. I must 
> admit I've not looked very hard.

no, not yet discussed.
 
 
 
> 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.

yep, nice.
 
> 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/.

right, we might want to fix that for depmod to have it shipped a postinst.
 
> 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.

i don't know if waldi's rewrite aka the dkt - debian kernel toolkit
uses the infrastructure, guess not, maybe waldi can highlight his plans?
 
> DEB-PKG PATCHES
> ===============
> My patch series for the upstream kernel contains roughly the following 
> changes:
> - some minor cleanup

would be nice to see, can you post those linux-kbuild.
maybe as followup on mine, maybe we step on each toes with those ;)
script is not huge.

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

don't think /etc/kernel.custom is a good idea.
i'd be more happier to move that to /lib like udev that moved from
/etc/udev/rules.d/ to /lib/udev/rules.d/
 
> 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...

why not ideal?
have seen this same critic by k-p maintainer, but it didn't get backed up.

if you read initramfs-tools changelog you'd see that a first attempt
to have make deb-pkg support was done for lenny but failed 
due to double removal of same initramfs irc.
aka #499270 version 0.92k->0.92l

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

dont think so.
 
> 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.

nah not very useful, enforcing correct file name ending with .sh
might be more worthwhile.
 
> 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.

no conffile.
users shouldn't care to much about these details.
i'd prefer a /lib location and if you still see it worthwile
for powerusers the /etc conffile?!
 
> 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

no extra package should be needed linux-2.6 make deb-pkg should 
have it's postinst fixed and should work standalone that is the
main point and greatest bonus.

have it fixed upstream for all and everyone. :)


thanks for your input and looking forward on make deb-pkg hackery.

-- 
maks