[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Fedora-packaging] Re: atrpms kernel modules



dropping fedora-list from CC

Hi All!

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.

> 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).

All special handling I'm aware of is that all modules that have

Provides: kernel-modules

are installed by yum and not updated. Similar how all packages providing
"kernel" are installed and not updated. Yum support that for a long time
(two years?) already (IIRC). The latgest version seems to also have some
magic to updat kmod packages if there would be conflics otherwise.

> 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.

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.

> 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.

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:

- yum should install kmods for all latest kernels that are installed --
e.g. is one has a smp and a xen0 kernel installed yum should install
kmods for both when running "yum install kmod-foo"

- plague needs support for kmod-srpms to get rid of the hard coded
kversion and kvariants

>> 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_.

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.


CU
thl


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]