Re: ABI handling for linux-2.6
On Wed, Jun 07, 2006 at 10:39:59PM +0200, Frederik Schueler wrote:
> Hello,
Thanks Frederik for taking over this issue :)
> 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.
>
>
> 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.
I think either of those solution would be neat. Another would be an engagement
by the ftp-masters to not cause unduly delays, and having a fast-path to
communicate with them about our needs. I personally favour the first option,
since there is really no reason for the ftp-masters to double check on our
work, but hey ...
> 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.
This would suck big time and would be a serious step backward over what we
currently have. I am not sure that accelerating the NEW process is worth this
loss.
> To accomplish this, we need to take care of the following:
>
> - Build the out of tree modules along with the linux-2.6 package.
Yeah, but then we need to reupload a new kernel package for every out-of-tree
module change.
> - 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).
>
> - 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).
Yep, it would mostly kill support for third-party modules.
> - 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.
We can propose some scripts which will always keep the latest X known working
kernels around and their initrd, out of the package that is. This could be
done with a script which would be run at a very late stage of the boot
process, and saved the known working kernels, and edited the bootloader config
accordyingly. This would be a good thing to do anyway.
> We would be glad if we could find a consensus on one of these options (or
> another, please point it out here if you have one) within the end of
> next week, so we can inform the release- and ftp-master teams on our
> consensual decision.
Ok, you have mine here.
> Thus we would like to propose as ETA Sunday June 18.
Friendly,
Sven Luther
Reply to: