[repo-coord] Re: kernel module versioning

[Axel Thimm]

On Thu, May 06, 2004 at 02:21:56PM +0200, Bent Terp wrote:
> On Thursday 06 May 2004 13:40, Axel Thimm wrote:
> > > For the confused (which includes me!) - Is the "broken versioning
> > > scheme" the one Panu talks about here?
> >
> > No, that's the sane one, i.e. one that contains the kernel
> > version/release in the name tag of the rpm.
> 
> Are you 100% on this? Here's what I got from a cuztomized query on my box:

Yes, see also Panu's reply, he should be sure at least ;)

> [bent at latte bent]$ rpmquery --queryformat="Name: %{NAME}\n\tversion: 
> %{VERSION}\n\trelease: %{RELEASE}\n\towner:  %{PACKAGER}\n\tbuildhost: 
> %{BUILDHOST}\n" kernel kernel-module-alsa kernel-module-ndiswrapper 
> autofs4-kmdl-2.4.22-1.2188.nptl
> 
> Name: kernel
>         version: 2.4.22
>         release: 1.2188.nptl
>         owner:  Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
>         buildhost: daffy.perf.redhat.com
> Name: kernel-module-alsa
>         version: 1.0.4
>         release: 1_2.4.22_1.2188.nptl
>         owner:  Matthias Saou <matthias.saou at est.une.marmotte.net>
>         buildhost: python2.freshrpms.net
> Name: kernel-module-ndiswrapper
>         version: 0.7
>         release: 1_2.4.22_1.2188.nptl.rhfc1.dag
>         owner:  Dag Wieers <dag at wieers.com>
>         buildhost: lisse.bertem.wieers.com
> Name: autofs4-kmdl-2.4.22-1.2188.nptl
>         version: 4.1.0
>         release: 3.20031201.rhfc1.at
>         owner:  ATrpms <http://ATrpms.net/>
>         buildhost: bach-rhfc1.atrpms.net
> 
> When I see the filenames involved, I tend to get confused as to which of all 
> the dashes separate N-V-R, thus the custom query.

In the above the autofs module uses the technically needed
version-in-the-name method, the two other modules do not, and the
kernel, of course does not have to.

> What I did with my new lappy was
> - "apt-get install kernel", got lotsa suggestions back
> - "apt-get install kernel#what-looks-newest", reboot to new kernel
> - "apt-get install kernel-module-alsa kernel-module-ndiswrapper", and voila 
> time to modprobe.
> 
> Next, I did
> - "apt-get install autofs4-kmdl", got some suggestions
> - "apt-get install autofs4-kmdl-what-seems-to-fit-my-kernel", discovered I 
> needed a userspace package as well
> - "apt-get install autofs"
> 
> For now, both ways of naming seems to work, but from what I've understood so 
> far (or MISunderstood, mayhaps?), the packages with %{NAME} = 
> "kernel-module-alsa" and "kernel-module-ndiswrapper" upgrade alongside the 
> package with %{NAME} = "kernel".

For those two modules the upgrade path of the kernel and that of the
module have been mixed. For autofs4 they are kept separate effectively
disabling the kernel upgrade path. So autofs will continue upgrading
_per kernel_, while the other kernel modules have a flat upgrade path.

In the dicussion two months ago there were several scenarios/examples
discussed which demonstrated that mixing the kernel version/release
with the one from the module will break. Either the kernel modules
will be upgraded (not co-installed) across kernels (very bad), or you
will be installing (not upgrading) multiple versions of a kernel
module per kernel by disabling rpm's upgrade consideration with
AllowDuplicate (also very bad).

From a scientist POV it is the problem of applying a one-dimensional
operator (the comparision operator in rpm) to a two-dimensional
configuartion space. Since this is not possible, one dimension has to
be projected away, either the kernel "age" or the module "age". As it
is more natural to allow upgrades of kernel modules within the same
kernel, the more invariant part is the kernel's version/release data,
and this gets out of the play only by shoving it into the name tag of
the rpms. There isn't any other solution given the rpm/deb design.

BTW you get the same problem exactly for anything acting like a plugin
to another package. kernel modules are only "plugins"to the kernel
from rpm's POV. so the same solution here applies to xmms or mozilla
plugins, e.g. shove the base system's version/release into the
plugin's name.

> How does that work for %{NAME} = "autofs4-kmdl-2.4.22-1.2188.nptl"

The usual way is to do

OLD=2.4.22-1.2179.nptl_47.rhfc1.at
NEW=2.4.22-1.2188.nptl_48.rhfc1.at
rpm -qa --qf '%{name} ' \*kmdl\*${OLD}\* | sed -e"s,$OLD,$NEW,g" | xargs apt-get -y install

This replicates all kmdls for the OLD kernel for the NEW, too. The
old kernel modules will not be removed. This works consitently at the
rpm level.

apt has Panu magic (he is humble enough to prefer to call it lua magic
;), that does the above from within apt itself. There is no such
solution for other resolvers like yum currently.

> Is that where the "lua magic" comes in? If so, it's archmage-level
> stuff and not for mere apprentice wizards like me ;-)
> 
> > The kmdl vs kernel-module, or module name before or after these is
> > a purely non-technical issue.
> 
> Yes, that's just flavour I understood that much, some prefer chocolate and 
> some vanilla - I eat both, especially when they're free :-D
-- 
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.atrpms.net/pipermail/repo-coord/attachments/20040506/47173b24/attachment-0001.bin