[elrepo-devel] kmod packaging cleanup for rhel-6

[Phil Perry]

On 31/07/10 14:19, Farkas Levente wrote:

Hi Levente,

>
> my goal is to update /usr/lib/rpm/redhat/macros in redhat-rpm-config in
> a way to be able to use it by rh, elrepo and all 3th party developer
> who'd like to build kmod rpms.
>
> at the same time it'd be useful if yum can handle kmod rpm in the "right
> way". and here i define "right way" that on an rhel system kmod packages
> should have to updated ie. only one version of the same packages can be
> installed (since all kernel are kabi compatible in a rhel release).
> currently it's not the case:-(
>

Personally I agree, hence why we have hacked kmodtool to allow for that.

> let's start with this last one (it seems to be easier). the problem is
> that kmod packages virtual provides kernel-modules (through kmodtool or
> %kernel_module_package).
>
> obviously there are two way:
> - patch yum to handle kmod rpms as normal package.
>    https://bugzilla.redhat.com/show_bug.cgi?id=572883
>    https://bugzilla.redhat.com/show_bug.cgi?id=502140

Referring to your comment 6 in bug #50214,

==quote==
how can be usable kmod-foo-1.0 and kmod-foo-2.0 at the same time when 
both use
weak-updates (as used in el kmod pacakges)? imho the problem here is 
that there
is no reason to include kernel-modules in this list.
==end quote==

I can think of one instance where that might be useful, and that is 
where kABI compatibility breaks between kernel series. Suppose you build 
kmod-foo-1.0 against 5.0 and it's compatible up to and including 5.2 but 
breaks for 5.3 and above. Then you may want to build kmod-foo-2.0 
against 5.3 and allow users to have both installed at the same time so 
they are able to use the driver with any 5.x kernel. Obviously this 
situation isn't ideal and one would prefer to only have to support the 
latest kernel update series, but one has to accept there might be 
situations where allowing more than one version of a driver package to 
be installed might actually be useful. Where it is completely 
nonsensical is where two versions of the same driver package both 
provide the same files (i.e, are built against the same kernel) - for 
example, a minor update from kmod-foo-1.0-1 to kmod-foo-1.0-2.

If Red Hat were to change the default behaviour, and allowed updating of 
kmod packages by changing kmodtool in the way we currently do, it would 
still be easy for us to revert that changed behaviour where needed. 
Hence my preference would be to leave kernel-modules in installonlypkgs 
and hack kmodtool to change the default behaviour.

>
> now go back to the main kmodtool or %kernel_module_package problem.
> there was long discussion about it:
> http://lists.elrepo.org/pipermail/elrepo-devel/2009-August/000018.html
> related bugs:
> - wrong requires and buildrequires in kmodtool
>    https://bugzilla.redhat.com/show_bug.cgi?id=583839
> - weak-modules fails to create weak links when updating kmod packages
>    https://bugzilla.redhat.com/show_bug.cgi?id=593504

I think Red Hat will probably revert bug #593504. See here:

https://bugzilla.redhat.com/show_bug.cgi?id=477089

In the mean time we intend to implement the workaround proposed by 
Martin Wilck in bug #593504 and have shipped an updated 
module-init-tools to that effect reverting the patch.

>
> another small (bug?):
> - kabi-yum-plugins name:
>    https://bugzilla.redhat.com/show_bug.cgi?id=612826
>

That one would also be worth mentioning on the RHEL6Beta mailing list 
too, or did I miss it there?