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. 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. 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. To accomplish this, we need to take care of the following: - Build the out of tree modules along with the linux-2.6 package. - 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). - 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 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. Thus we would like to propose as ETA Sunday June 18. Best regards Frederik Schueler [1] http://lists.debian.org/debian-kernel/2006/05/msg00479.html -- ENOSIG
Attachment:
signature.asc
Description: Digital signature