On Wed, Aug 16, 2006 at 11:04:31PM +0100, Jon Masters wrote:
On Wed, 2006-08-16 at 22:36 +0200, Axel Thimm wrote:
> On Wed, Aug 16, 2006 at 08:09:22PM +0200, Thorsten Leemhuis wrote:
> > Axel Thimm schrieb:
> > Nope, /sbin/weak-modules {cs}hould handle this.
> So adding evr semantics to module-init-tools? BTW where is the epoch
> in your file path suggestion? ...
> Gotcha! :)
I'm already adding a conf.d to m-i-t (but still toying with the exact
implementation to be figured out over this week) so you can specify the
priorities for individual /lib/modules directories. This is actually to
solve another problem, which is that sometimes you might want to use
kmods to override the built in kernel modules, sometimes not but you
might also want to *explicitly* set behavior in the module RPM.
You could (a)buse this to override the ordering of modules if we
switched to a new packaging system. Right now, the ordering of
directories in our m-i-t is:
* Try /lib/modules/*/updates - if there, the admin did it.
* Try /lib/modules/*/extra - if there, it's in a current kmod.
* Try /lib/modules/* - if in the kernel, cool.
* Try /lib/modules/weak-updates - if there, /sbin/weak-modules did it
when looking to find compatible modules on kmod remove/install.
With kabi checking enabled (if you package with kABI deps) then you get
for free the compatibility links automatically added/removed on module
install/remove so older kernels can use a more recent kmod. You will be
able to ultimately instruct module-init-tools to always use the version
of a module in weak-updates over the built-in kernel and thereby get a
given module to always be available to all compatible installed kernels.
My personal opinion is that it's too late to change kmods drastically in
FC6. I think now we're all starting to think about the overall packaging
process again that we should have discussions this week about what to do
in FC7 and beyond - unless there's a major flaw in kmods (and I don't
think we can count any of the existing arguments as sufficient reason to
rip out the current status quo at T2 stage) we should leave it for FC6.
Jon.
--
Jon Masters Phone: +44 7776 131337
Red Hat UK, Ltd. Email: jcm(a)redhat.com
--
Fedora-packaging mailing list
Fedora-packaging(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
Jon,
Do I understand this correctly?
Grub doesn't know anything about RPM versioning but it knows what kernel
to boot because the kernel package / up2date / whatever runs a tool that
says make this the default kernel.
I've gleaned so far that the mit tool will be used similarly with kernel
module packages to say "use this module as the default in kernel version
foo." The user/admin can use the mit tool or whatever to adjust which
modules get used with his own packages or configuration management
tools as is needed by his requirements.
Jack
--
Jack Neely <jjneely(a)ncsu.edu>
Campus Linux Services Project Lead
Information Technology Division, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89