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 <sriva...@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
