On Thu, 2006-08-17 at 06:41 +0200, Ralf Corsepius wrote:
> Agreed, like we agree upon "apps go to %{_bindir}", "libs go to
> %{_libdir}", we need a clear and strict convention on where
> kernel-modules need to be installed.
There is *no need* for kernel modules to go in /lib/modules/kver at all
- that's just a convention for built-in kernel modules and I see no
reason why we can't have m-i-t pick up modules from other sane locations
too. If we can persuade people to use proper MODULE_VERSION()s then we
can also sanely decide about which of several versions to use.
Here's one random (not thought it all through) idea:
* Install modules in %{_moduledir}/modulename/kver
Then an RPM provides just the module for whatever kernel versions it
wants. But we still need to solve the issue of compatible modules. I
quite like the idea of insmod/depmod no longer basing its decisions on
data available from depmod using the location of the module, but the
compatibility of the module (kABI checks). So we say this:
* m-i-t tries to load %{_moduledir/modulename/this_kver
* m-i-t falls back on %{_moduledir/modulename/configured_ordering
* m-i-t falls back on /lib/modules/this_kernel
And weak-modules goes byebye because we don't need symlinks any more. We
make depmod and insmod/modprobe much more configurable and ship a def.
config with some sane options, but allow anyone to have old behavior or
more configurable and flexible behavior depending on their config.
What I'm saying is that I'm happy to try out some pretty radical
solutions to this problem now that I'm maintaining m-i-t. If we can have
a serious discussion about what we *want* from a "perfect system" then
we can make it happen properly upstream and get other folks involved -
we're not the only people who want to package up modules and agree on
standardized locations and mechanisms for choosing updated drivers.
I have spoken to the folks at SuSE/Novell and Ubuntu about driver
packaging - though not all the interested parties. I would /really/ like
it if some of these non-RPM-specific issues could get solved generally
or at least involve the other players who actually use the tools.
I am however /very/ sure that I don't want to try radical stuff ahead of
lots of community involvement. In Fedora terms, that means my own
personal view is it's way too late to be changing things for FC6 (unless
it's decided it's not). I would like us to get somewhere today/this
week/whenever towards sensible discussion of ways to fix the problems we
have in FC7/etc. and beyond - where IMO we have the time to spend on it.
Jon.
--
Jon Masters Phone: +44 7776 131337
Red Hat UK, Ltd. Email: jcm@xxxxxxxxxx
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
