(dropping ltsp as the list is moderated)
On Wednesday 01 April 2009, maximilian attems wrote:
> On Wed, 25 Mar 2009, Frans Pop wrote:
> > 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.
Hmmm. IMO the discussion is Debian internal (derivatives might be
interested). It could result in adjustments to deb-pkg, but I don't see
why l-kbuild want to participate in the discussion.
> > 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.
I assume:
s/shipped/include/
s/postinst/postscript hook script/
> > 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.
Posted to linux-kbuild now.
> > - 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.
Note that I do not proscribe /etc/kernel.custom in any way. I'm just
offering the user the option to specify a different location from
/etc/kernel, so that he has the *option* to use a completely separate set
of scripts for custom kernels than any standard hook scripts. What path
they use is completely up to them.
> i'd be more happier to move that to /lib like udev that moved from
> /etc/udev/rules.d/ to /lib/udev/rules.d/
Hmm. I thought one of the points for udev was that users can define (at
least add) their own rules. I assume there's still a mechanism to add or
override the standard scripts under /lib in /etc?
IMO the same goes for the kernel hook scripts. Definitely something that
should be considered carefully.
The default for deb-pkg should IMO remain /etc/kernel in order not to
break things for existing users. If you move to /lib and users want to
follow, they can use my mechanism.
> > 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?
Because it relies on a very specific, largely accidental difference
between implementations. What if we decide that we _do_ want to use a
second parameter for something.
My suggestion set the origin of a build in an envvar is more flexible.
> 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.
I agree that it's an issue. For me double runs of the boot loader update
was the reason I wanted the alternative hook dir option.
> > 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,
Eh? Then how are you going to ensure update-initramfs runs before
update-grub? Alphabetically they are in the wrong order.
> enforcing correct file name ending with .sh might be more worthwhile.
That's discouraged by policy (except maybe for files that are sourced).
> > 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
>
> no conffile.
> users shouldn't care to much about these details.
Most users probably won't care, but I still think you underestimate this.
Especially if make-kpkg and official kernels are going to use the same
hook dirs.
> i'd prefer a /lib location and if you still see it worthwile
> for powerusers the /etc conffile?!
If there is a clear mechanism for overruling the standard scripts that
could work.
> > 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
Having module-utils provide the hook script could work.
> > - 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
That's a rather unsubstantiated opinion. Could you elaborate how you'd
solve the points I listed here?
> linux-2.6 make deb-pkg should have it's postinst fixed and should work
> standalone that is the main point and greatest bonus.
I don't understand what you're saying here. I actually _like_ the simple
hook script mechanism of deb-pkg as it allows me to very simply have
different things done for different architectures.
What's broken about the deb-pkg postinst?
What do you mean by "standalone"?