[Fedora-packaging] Re: atrpms kernel modules

Wed Jul 19 22:37:17 UTC 2006

On Wed, Jul 19, 2006 at 07:40:38PM +0200, Thorsten Leemhuis wrote:
> Seems Axel wants to bring kmod onto the topic again -- I can understand
> his situation so let's get this discussed...
> 
> Axel Thimm schrieb:
> > On Tue, Jul 18, 2006 at 01:59:34PM +0200, Eric Tanguy wrote:
> >> 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.
> 
> Well, yes, coinstall will fail because this would result in a file
> conflict. But rpm -U works fine (but removes the older version) with the
> current Extras kmod scheme and "yum install foo" AFAICS works fine, too.

No, rpm -U would remove both kernel modules from both kernels and only
install the selected kernel module, you end up with one kernel losing
the kernel module w/o replacement.

rpm -U will always leave only one kernel module package behind unless
these packages are disambiguated in their name by extending the name
to contain the kernel's uname -r.

> Well, we (fedora.us and Livna in this case) had a scheme that used
> the output from "uname -r" in the name similar how atrpms still uses
> it AFAICS. We (e.g. those involved in the kmod discussion for
> Extras) were not satisfied with it AFICS.
> 
> The decision against using the uname-output in the name was one of
> the first ones when the Extras kmod-standard was discussed. It was a
> rather quick decision IIRC to not use it.

I wished I had been involved at that time to argue against this
unfortunate change, but probably it was during the "cold war" where
most people including myself had run out of batteries and could not
try to save the world anymore :)

Anyway it's never too late, I'm optimistic about the new world
order. :)

> > 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
> 
> Is you scheme documented somewhere properly so we can look at it again?
> Please also post a URL to the macros for FC5 (maybe rawhide, too) -- we
> probably need them if we want to look at the scheme.

I committed myself to prepare some documentation after asking in the
packaging group whether there is general interest to review this part
of the guidelines.

Not only on the actual usage but also on the rationale behind it
hoping that some design decisions will become more apparent. In this
sense this thread is perhaps a tad too early, but it was triggered by
some user discussion and led naturally to explaining some parts of it
with mentioning the review proposal. But since it got started (which
is a good thing) we should not let it drown again. I'll try to prepare
the docs ASAP.

> BTW, livna uses the Extras scheme for all kmod-packages since FC5 now.
> AFICS it works a lot better than the old fedora.us scheme. There are
> still some things that could need to be improved:

But if it's broken already at the rpm level how can it be better? You
can start teaching yum special handling, then smart and finally apt
and maybe up2date since the scheme is to be used in RHEL at some point
in time. But is this really the way to go?

Admittedly the kmdl scheme or the old livna scheme with the uname -r
in name also need some special handling, but it's easier to add the
coinstall logic (e.g. 9 lines of bash code were already anough) and
the drawbacks w/o that special handling are far less severe (e.g. you
never run into the situation that you might blow away kernel modules
of unrelated kernels with a simple rpm -U).

To summarize:

o schemes w/o uname -r in name
  - break at rpm level
  - depsolver special handling is therefore a *must* otherwise old
    working kernel may get their kernel modules nuked. And even if all
    depsolvers will be patched to take this into account you are still
    broken on rpm level.

o schemes w/ uname -r in name
  - no coinstalls at rpm level
  - depsolver special handling is *nice-to-have* otherwise new kernels
    won't "inherit" kernel modules installed for old ones. In the
    worst case users have to manually reinstall kmdl after/during each
    kernel upgrade.

The latter "worst-case" scenario is what ATrpms ships for a couple of
years now. kmdl at ATrpms be it for multimedia (ivtv, v4l, nvidia) or
for wireless (ipw*, madwifi) have a large userbase that seem to cope
well with reinstalling kmdls after a kernel upgrade (it's just the
9-liner bash scriplet after all). So field experiance if you'd like to
call it, already shows that uname-r-in-name schemes are indeed
consumable.

> > 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_.
> 
> As I said,
> Provides: kernel-modules
> and yum will install them. When you run rpm directly you are on your own
> -- it similar with the kernel itself.

No, with the kernel it's always just rpm -i, never rpm -U, that's all
a user needs to know. With kernel modules w/o uname-r-in-name you can
easily run into a situation where you need something in between like
the example above: Coinstall wrt to an installed kernel module package
for another kernel, but upgrade any installed kernel module package
for the matching kernel.

In order for a depsolver to get that logic installed you need to
reverse engineer the two dimensional versions of modules and kernel
out of the kernel module package and define a completly new
"upgrade/coinstall" mechanism with is definitely not any more rpm CLI
compatible. And losing that only because kernel modules packages w/
uname-r-in-name look ugly isn't worth it.
-- 
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-packaging/attachments/20060720/938218e5/attachment.sig>