Hacking modversions

David Zeuthen david at fubar.dk
Tue Mar 1 23:10:03 UTC 2005


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





More information about the devel mailing list