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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
