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
Attachment:
pgpYDCKx6GkDH.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
