atrpms kernel modules

[Axel Thimm]

On Tue, Jul 18, 2006 at 01:59:34PM +0200, Eric Tanguy wrote:
> > kernels=`rpm -qf /boot/vmlinuz-* | grep -v "^file .* is not owned by any package"`
> > uname_rs=`rpm -ql $kernels | grep ^/boot/vmlinuz- | sed -e's,^/boot/vmlinuz-\(.*\)$,\1,'`
> > for kmdl in `rpm -qa \*kmdl\* | sed -e's,-kmdl-.*,-kmdl,' | sort -u`;
> > do
> >   for uname_r in $uname_rs; do
> >     package=${kmdl}-$uname_r
> >     rpm -q $package > /dev/null 2>&1 || echo $package
> >   done
> > done | xargs -r smart install -y
> 
> Ok this script seems to use smart. is it working with yum ?

Yes, I think "smart install -y" -> "yum -y install" is the only change
needed. And for apt it would be "apt-get -y install".

> How is this problem handled by livna because it works fine using
> this repo : the kernel modules are installed and not updated

> It's known that there are issues with this scheme, or any scheme
> that will merge module and kernel versions.

rpm for one can't cope with it. Suppose you have two active kernels
(say 2.6.16 and 2.6.17 or xen0 and non-xen0 etc.) and already have
foo-kmdl for both in version 1. Now foo-kmdl in version 2 is
released. Both rpm -i (coinstall, no replacement of of foo-kmdl for
the same kernel) and rpm -U (remove all foo-kmdl but the highest one,
e.g. at least one kernel stay w/o any kmdl) won't work.

yum/smart/apt can be tought to be more clever than rpm and try to do
the proper thing, which they will only be able to do if the merged
versions are distangled again, e.g. hidden in Provides: and the like.

So in order for a merged-version scheme to work there is special
handling neccessary (and for atrpms' system, too, but read on). I
prefer to have rpm itself already do something sensible and since it
can only upgrade one versioning system (e.g. either the kernel's or
the module's) it's preferable to allow it to upgrade the module within
the same kernel and not touch the cross-kernel boundaries. "No harm
done" like accidentially removing kmdls for other kernels or
coinstalling several kmdls for the same kernel. You "only" need to
reinstall the missing kmdl upon each kernel upgrade.

It's far easier to get this into the brains of yum/smart/apt
(e.g. translate the 9 lines of bash above into plugings/hooks for
these depsolvers) or simply use the 9liner above than have a scheme
which is broken at the level of rpm.

Incidentially one on my personal targets is to get thie discussed in
the fedora packaging group and review the currently scheme. Of course,
I'm proposing adoption of ATrpms' kmdl scheme :)

http://www.fedoraproject.org/wiki/Packaging/GuidelinesTodo

> when i install a new kernel and are removed when the kernel is
> removed.

How the dependencies to the kernel are installed (which is responsible
for having an automatic removal on kernel removal) is a different
story, which the version merging does not break. The issue is with the
system (system=rpm and(or any higher depsolver tool,
e.g. yum/smart/apt) being able to distinguish different foo-kmdls as
_upgrades_ vs _coinstalls_.
-- 
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://listman.redhat.com/archives/fedora-list/attachments/20060718/7557ee5f/attachment-0001.sig>