Re: ABI handling for linux-2.6
Frederik Schueler <fs@debian.org> writes:
> Hello,
>
> After having discussed the current ABI and NEW handling problem with
> Bastian Blank, we would like to seek a consensus among the kernel team
> members concerning these issues.
>
> To shortly draft the main issue: upstream changes ABI fairly often
> (looking for example at the 2.6.16.x series, we had 3 ABI changes in
> 20 revisions, of which two where resolved without ABI bump in our
> package), causing the linux-2.6 package to be delayed in NEW every
> other upload.
3 ABI changes, 2 of them didn't bump the ABI. So in fact only one
package rename in 20 revisions? Doesn't that mean 1 in 20 uploads was
stuck? Or am I missing something?
> Looking through the recent thread[1] on this topic, basically two
> options come to mind:
>
> 1. Alter the NEW handling for kernel (and out of tree modules) packages:
>
> - Add some kind of auto-hinting (if this is technically possible) to
> automatically process kernel packages and co.
>
> - Grant ftp-assistant rights to someone from the kernel team, who will
> process these packages only.
It would already help if ftp-assistant had the right to process
kernels through NEW and would use that right (maybe they already do
have it). Also maybe kernel uploads could trigger a mail to be send
out to all ftp-assistants so they quicker see it in NEW without having
to manualy check or something.
> 2. Remove the ABI information from the package file names, possibly even
> renaming the linux-image packages to linux-image-2.6-arch-flavor to
> avoid NEW runs even on new minor releases.
Move the package ABI from the package name into provides.
> To accomplish this, we need to take care of the following:
>
> - Build the out of tree modules along with the linux-2.6 package.
Out of tree modules can just use the provided abi just like they use
the name now.
> - Remove the ABI from the packages files names.
>
> - Have the out-of-tree modules Depends: linux-2.6.x-arch-flavor (== 2.6.x-x).
Right, move them into provides and get make-kpkg / module assistant to
pick that provides as dependecy for out of tree modules.
> - Update module-assistant and kernel-package to build modules with
> the same strict dependency on the linux-image it was built for.
>
> Drawbacks:
>
> - We would not have a stable kernel ABI anymore, with all the
> consequences for custom built modules or third-party modules from
> other vendors (symbol version mismatches).
>
> - The user would have only one kernel installed - if that one
> breaks on upgrade, the user is left with an unusable system.
> A solution for this could be to not call the packages
> linux-image-2.6-arch-flavor but linux-image-2.6.x-arch-flavor, which
> in return will cause a NEW run every new upstream minor release.
> This still does not fix the problem of ABI changes breaking the users
> setup.
Option 2+)
Create a kernel/module manager that will be in control of the
lilo/grub/whatever bootmanager config, the kernel images, the initrd
and the modules for each version. On install the kernel/module
packages call the manager which then copies the kernel/modules into
the right place and generates the initrd.
This means that the packages can't ship /lib/modules/* or
/boot/vmlinuz* files but have to keep them somewhere else. A
kernel/module.tar.bz2 file is probably most efficient. The manager
would unpack them when getting called in postinst.
Advantage:
- Old kernels can be kept installed or overwritten depending on
changes in the ABI without the need to change the package name.
Drawback:
- Takes more space because every kernel/module gets copied.
- Needs what basicaly comes down to a simplified dpkg.
- Second package management tool to remove packages, dpkg --pugre
pkg won't do it anymore.
[As a _proof_of_concept_ the linux-2.6.deb could contain the
linux-2.6.x.y.deb and call dpkg -i with a seperate admindir from
postinst.]
This certainly isn't the most elegant but I just wanted to throw it in
as a crazy option. Maybe someone can make something out of it.
MfG
Goswin
Reply to: