| 2008-06-30 18:06:03 |
Rehan Khan |
description |
Imported: http://tracker.labix.org/issue17
http://tracker.labix.org/issue174
http://tracker.labix.org/issue332
Reason for Import: Feature request review
further details: https://blueprints.launchpad.net/smart/+spec/bug-reporting-migration |
Imported: http://tracker.labix.org/issue17
http://tracker.labix.org/issue332
Reason for Import: Feature request review
further details: https://blueprints.launchpad.net/smart/+spec/bug-reporting-migration
Issue 17:
msg44 (view) Author: thimm Date: 2005-10-09.22:01:23
Some time ago we discussed on how to manage kernel modules. These packages have
two versions, one for the kernel they have been built for and one for the module
itself.
The current most successful handling is to stuff the kernel's version into the
package's name and thus have a proper one-dimesnional module upgrade path within
one version of a kernel. The drawback is that kernel modules for different
kernels now have different package names and connot be related anymore for
upgrade considerations (one reason this has been done, is to avoid upgrade
considerations that would remove the kernels modules of a sibling kernel, see
below).
The missing bit is to have smart automaticaly install kernel module packages
(kmdls) upon kernel upgrades. This requires special handling, as the packages'
names are different for the new kernel than they were for the old one.
A shell script way to do it is
OLD=2.6.11-1.14_FC3
NEW=2.6.11-1.27_FC3
rpm -qa --qf '%{name} ' \*kmdl\*${OLD}\* | sed -e"s,$OLD,$NEW,g" | xargs smart
install -y
E.g. replicate all foo-kmdl-<uname-r> packages for the new <uname-r>.
I couldn't find the mails from March in some archive, so I'm pasting in the last
mail on the subject with some lengthy example to illustrate the issue. Thanks!
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. :)
Issue 332:
msg1201 (view) Author: peter-endian Date: 2007-10-04.22:22:51
This is the szenario:
I have a package "kernel" which requires some "kernel-module-*" packages of the
same version. (Requires: kernel = %{version}-%{release})
Those packages are all multi-version.
I have installed several kernel-packages of different versions with their
respective kernel-module-* packages
Whenever i want to remove a old kernel package by version (smart remove
kernel-2.6.9-55.0.2.EL.endian21), smart wants to remove only that package, which
leads into an error since the kernel-module-* packages require the kernel
package with the specific version:
Removing packages (1):
kernel-1:2.6.9-55.0.2.EL.endian21@i386
Committing transaction...
error: kernel-module-fcdslslusb-3.11.04-4.endian4_2.6.9_55.0.2.EL.endian21
requires kernel = 1:2.6.9-55.0.2.EL.endian21
...
I solved the problem by setting immediateUpdown = 0
Here is what i found out during debugging:
Within class TaskRemove, method _remove, TaskUpDown will be called for each
package which requires the kernel package if immediateUpdown is 1.
Normally, TaskUpdown would upgrade (or downgrade) the kernel-module-* packages,
which would implicitely remove the old packages.
But in this case this has not been happened because of multi-version.
TaskUpdown now will upgrade the kernel-modules-* packages, but the new versions
of them are already installed, so there is nothing to do for TaskUpdown.
But in order to fulfill requirements for the to-be-removed kernel package it
must remove those packages.
|
|
