On Thu, Mar 23, 2006 at 12:13:16AM -0500, Joey Hess wrote: > Jurij Smakov wrote: > > * Automatic rebuilds (configurable) on kernel updates. Nothing fancy, just > > a transparent way to figure out whether the currently installed > > kernel module source is compatible with the new kernel, and attempt > > rebuild and installation, if neccessary. > > The thing I really want to see is a way to guarantee that a binary > module package will get updated in the debian archive when the kernel is > changed. Until we have this guarantee, there's really no way the > installer can reliably depend on out of tree modules that need to be > used for anything during installation, and there's no way the installer > can reliably cause these module packages to be installed on the target > system. > > I collolary of that last is that there also needs to be a way to ensure > that module packages are always upgraded when the kernel is, which > probably would mean doing something tricky with module package names and > dependencies.
I may have misunderstood you, but my understanding was that the abi number of the kernel, and a proper dependency to it, would solve a part of this problem. The rest is to make sure that in etch (no guarantee possible for sid) the module .debs and .udebs are in sync with the kernel versions, but i believe the testing script, provided we do propper dependency handling, will take care of that. This impose a better discipline on the module rebuild. we need at least to have a list of them, and then automatically triger rebuild, and examine all failures at a case-by-case situation. Failure should be RC and enough to kick the packages out of testing, as the main kernel has priority. I believe, but this needs probably some work, that the binary-NMU rules for auto-rebuilding packages on the buildds, probably needs some adaptation to this case, which would allow to regenerate the control file to match the new kernel version-and-abi. Maybe for post-etch some rethinking of the contorl file and packaging tools may make this easier possible, i don't know. But we have a need here that hasn't been tackled previously. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
