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@xxxxxxxxxx
>
> --
> Fedora-packaging mailing list
> Fedora-packaging@xxxxxxxxxx
> 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@xxxxxxxx>
Campus Linux Services Project Lead
Information Technology Division, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
