On Tue, 2005-03-01 at 23:56 +0100, Fernando Herrera wrote: > Then, if we cannot stop breaking this modules we should think about >creating a little graphical tool for compiling/recompiling external >kernel modules (maybe a magic app and ugly application finding >makefiles, or some special file, dunno). Users can't, won't and shouldn't have to understand things like this. >But if Sally bought a webcam >that is not supported by the standard kernel, should we say to her >"Don't use linux, use Windows"? > Can someone explain to me why this is not a package management problem? Suppose some user is running kernel-2.6.10-1.1154_FC4 and types 'yum install kernel-module-foobar'. User gets this module from a 3rd party repo (cause otherwise it would just be in the kernel) with the following version kernel-module-foobar 2.6.10-1.1154_FC4-module_foobar_version_042 (meaning version 042 of foobar built against 2.6.10-1.1154_FC4) and it says Requires: kernel = 2.6.10-1.1154_FC4 Conflicts: kernel > 2.6.10-1.1154_FC4 Now, next time user types 'yum update', suddenly kernel-2.6.10-1.1155_FC4 is available. However, kernel-module-foobar is not updated yet so the update transaction fail (ok, maybe it's something other than Conflicts, expert packagers would know). Now, two hours later the 3rd party repo providing kernel-module-foobar has (automatically) respun the build of kernel-module-foobar and now provides kernel-module-foobar-2.6.10-1.1155_FC4-module_foobar_version_042 with Requires: kernel = 2.6.10-1.1155_FC4 Conflicts: kernel > 2.6.10-1.1155_FC4 and this makes the transaction succeed. The big part is of course getting the 3rd party repo to provide the automatic rebuilding of kernel-module-foobar which may require tweaking it to the upstream kernel interfaces. This may take time though since it leaves users depending on not-in-mainstream modules in a vulnerable state. However, I suppose time is best spent on automating tasks exactly like that instead of discussing pipe dreams about a stable kABI. At least for the short term. David