On Sat, Oct 15, 2005 at 02:29:59PM +0200, Jeroen van Wolffelaar wrote: > tags 331391 = confirmed > thanks > > On Thu, Oct 13, 2005 at 12:57:49PM +0200, Sven Luther wrote: > > Iti s an sarge -> etch upgrade problem if anything, let's remove them for > > now, > > and once we sorted out the module build issues, we can always readd them > > fori > > etch if really needed. > > It'd be convenient if the module building system were to be designed in a > way that modules that are not built with the current 'latest' kernel > package were to advertise that fact in a very obvious way -- for example, > that their dependencies and/or build-dependencies are broken if they are > for 2.6.12 while 2.6.13 is in the archive, for example. This would greatly > help in detecting what kernel modules in the archive are not uptodate in an > automated fashion using pre-existing tools (like debcheck and britney).
Normally, third party modules should include the exact abi version of the kernel they where built against in their package name. Not sure if this solved your problem, but after we solve the ramdisk generation tool issue, the next step is a fully new third party module policy. One solution would be for each kernel to provide a virtual linux-abi-<version>, and have each module package [build-]depend on it or something such, in a way similar to how ocaml handles its abi versioning. Need some thoughts still. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
