RFE: smart upgrade automatically installing kernel modules for new kernels?

[Axel Thimm]

Hi,

any chance this could be looked at? There is also a ticket on this.

This is the only real shortcoming of smart from my POV. I managed to
write a correspondig yum plugin in less than 100 lines of python, but
for smart I'm missing the hooks.

The operation is rather trivial it just needs to be hacked into smart
somehow. OK, I know, "send in a patch" :)

On Mon, Mar 28, 2005 at 08:50:19PM +0200, Axel Thimm wrote:
> Hi,
> 
> On Mon, Mar 28, 2005 at 11:00:09AM -0300, Gustavo Niemeyer wrote:
> > > As you pointed out previously, you don't want to replace the
> > > modules of the old kernel. Thus every kernel has its own set of
> > > independent kernel modules.
> > 
> > You don't want to replace the old kernel modules just like you don't
> > want to replace the old kernel itself. That's what the multi-version
> > flag is supposed to do: remove the inherent conflict between
> > packages with the same name without removing the upgrade relation.
> > 
> > > > A better way to solve that issue is to use the kernel EVR in the
> > > > package EVR, like this:
> > > > 
> > > >   kernel26-module-nvidia-2.6.9.68104cl.1.0.6111-68414cl
> > > 
> > > That's of the scheme foo-<kver>.<foover>-<commonrel>
> > 
> > Correct.
> > 
> > > But this is still doomed to break, when you simply upgrade the
> > > kernel, as the new package will be considered newer than this one
> > > and rpm has your old kernel w/o any nvidia modules anymore.
> > 
> > No, unless you have not introduced the right multi-version flags
> > in your smart configuration. We've been using that scheme for some
> > time with success.
> 
> OK, let's come up with an example. Suppose you have two kernels
> (2.6.10 and 2.6.11) with two versions of module foo (1.0 and
> 2.0). Here is an ASCII chart of what I'd like the system to setup as
> relations:
> 
>        module        1.0                           2.0
> 
> kernel
> 2.6.10                x    -- is replaced by -->    x 
> 		      ^				    ^
>                       |                             |
>                   is coinstalled               is coinstalled
>                       |                             |
>                       V                             V
> 2.6.11                x    -- is replaced by -->    x
> 
> And two diagonal relationsships with "is coinstalled".  "is replaced
> by" overrides "is coinstalled", so one should not end with both
> <2.6.11>.<1.0> and <2.6.11>.<2.0>.
> 
> multi-version flag would allow coinstallation, but I want to
> upgrade/replacement relations in the vertical segment to be killed
> while it should pertain in the horizontal.
> 
> That's why any one-dimensional scheme is doomed to break, and that's
> why the kernel EVRs are used to make the packages unique per
> kernel. The missing piece is the vertical auto-coinstallation.
> 
> If all four packages were tagged as multi-version and I would apply
> the scheme you suggested (foo-<kver>.<foover>, let's simplify release
> tags away), then the upgrade relations above would not work,
> especially not the relation "<2.6.10>.<1.0> is replaced by
> <2.6.10>.<2.0>", the system would go right ahead and find
> <2.6.11>.<2.0> (or even <2.6.11>.<1.0>) as a better upgrade
> alternative.
> 
> > > > That's a real example of how we handle this problem here.
> > > 
> > > How do you handle the above w/o special resolver logic? And if you
> > 
> > Upgrades happen as usual.
> 
> Given that the kernel EVR always wins in a merged scheme this cannot
> be true, see the example above. Unless you "abandon" the old kernel,
> in the sense that there will notr be any upgrades in that kernel line
> once you start working on a new kernel.
> 
> > Upgrades happen as usual. They only issue is telling Smart that these
> > packages should not have their old version removed when upgrading.
> > That's what the multi-version flag do.
> 
> But smart and any other tools does not know which of the updates to
> apply and how. In the example above, if the system has <2.6.10>.<1.0>
> and kernel 2.6.11 is to be installed in the current transaction, then
> the desired behaviour would be to
> 
> o upgrade <2.6.10>.<1.0> to <2.6.10>.<2.0> (i.e. remove <2.6.10>.<1.0>
>   in the process)
> o coinstall <2.6.11>.<2.0>
> 
> The scheme with the kernel's EVR in the packages name makes sure the
> first thing happens. The missing part is the installation for a new
> kernel (and not the "new" kernel could also be an old one which is
> explicitly asked for installation on the command line. The kernel
> modules should be installed for the "old" to-be-installed kernel, too,
> thus once again the coinstall scheme needs to be rpmvercmp agnostic).
> 
> > > breaks the notion of package upgrades, as these are not wanted for
> > > multiple kernel installations. I don't want rpm to start comparing
> > > kernel EVRs at all, just as it doesn't for kernels (well it does, but
> > > all higher level tools allow kernel coinstallation).
> > 
> > I don't understand. You say you don't want to compare kernel versions,
> > but you seem to be asking for a way to detect a new version when an
> > old version is installed in the system, and that's what upgrading is
> > meant to do.
> 
> Yes and no. What I would like to have is a mechanism that when certain
> packages are to be installed for whatever reason (the "kernel",
> "kernel-smp", "kernel-bigmem", "kernel-xen0" etc.) smart extracts
> their uname -r (e.g. their EVR with appended "smp" etc.) scans the
> installed packages for packages of the type *-kmdl-<uname -r> and
> replicates them in the current transaction with *-kmdl-<uname -r of
> the kernel* package to be installed>.
> 
> The rest (upgrades within a kernel) is taken care of automatically by
> the naming/version convention.
> 
> > > But any way to get the missing part of the puzzle ("auto-installs of
> > > already existing foo-kmdls") is very much appreciated, it would make
> > > smart a complete solution for the typical Red Hat/Fedora system.
> > 
> > We'll certainly build the missing parts somehow. ;-)
> 
> Yes, please :)
> 
> As a first step, when is distro.py run? Does it run at a time where a
> list of to be upgraded packages exist? Could it start by matching
> these packages against some given regexp and construct an uname-r out
> of this? E.g.
> 
> package			<uname -r>
> kernel		->	<VR>
> kernel-smp-EVR	->	<VR>smp
> ...		->	...
> 
> And for each of these extracted <uname -r> coinstall
> 
> rpm -qa \*-kmdl-`uname -r` | sed -e's,-kmdl-.*,-kmdl-<uname -r>,'
> (if these packages exist)
> 
> I understand that the issue is extremenly distro-specific, so it would
> all need to be banned into distro.py (perhaps with an example
> distro.py in smart's distribution?). But this would give a lot of
> added value to this corner of the rpm world, and I do believe that
> this kernel modules versioning scheme will find more followers in the
> course of time. :)



-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.labix.org/pipermail/smart-labix.org/attachments/20070515/9c3f15da/attachment-0002.pgp>