Bug 462099 - fedorakmod.py needs to recognize "kernel-modules-for-kernel" special require (PATCH)
Summary: fedorakmod.py needs to recognize "kernel-modules-for-kernel" special require ...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: yum-utils
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Seth Vidal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-09-12 16:25 UTC by Hans Ecke
Modified: 2009-01-29 15:31 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-09-30 21:39:05 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
add handling of special "kernel-modules-for-kernel" provide - tested on 2 systems (1.19 KB, patch)
2008-09-12 16:25 UTC, Hans Ecke
no flags Details | Diff

Description Hans Ecke 2008-09-12 16:25:51 UTC
Created attachment 316592 [details]
add handling of special "kernel-modules-for-kernel" provide - tested on 2 systems

Description of problem:

fedorakmod.py from yum-utils (distributed as the yum-fedorakmod package) has an algorithm to determine if a any installed kernel module packages depend on a kernel package. That way, a new kernel will only be installed if new versions of those module packages are available also.

The algorithm believes that fedora kmod packages have a special provide 

   kernel-modules = <kernel version> 

However, some existing kernel module packages - particularly from the external livna repository - do not have this special require, but instead one that is named "kernel-modules-for-kernel". Otherwise the semantics are the same.

It could be argued that the latter naming is more intuitive and explicit than the standard embodied in the current fedorakmod.py plugin.

Version-Release number of selected component (if applicable):

Rawhide (yum-utils 1.16 as of 12 Sep 2008)

How reproducible:

Each time

Steps to Reproduce:
1. Install livna kmod-ntfs or kmod-nvidia package
2. Install yum-fedorakmod
3. Set config in fedorakmod.conf to "pinkernels = 1"
4. Wait for a time when a new kernel is out in fedora repos - for instance today's 2.6.26; while livna has not yet published new module packages
5. "yum update"
  
Actual results:

It offers to install kernel-2.6.26

Expected results:

It should not offer to install kernel-2.6.26 because the corresponding kmod-ntfs and kmod-nvidia are not yet available

Additional info:

Patch attached

Comment 2 Hans Ecke 2008-09-30 21:46:19 UTC
Thank you, I appreciate it.

Hans

Comment 3 Thorsten Leemhuis 2009-01-28 18:20:36 UTC
Arghh :-((

(In reply to comment #0)
> fedorakmod.py from yum-utils (distributed as the yum-fedorakmod package) has an
> algorithm to determine if a any installed kernel module packages depend on a
> kernel package. That way, a new kernel will only be installed if new versions
> of those module packages are available also.
> 
> The algorithm believes that fedora kmod packages have a special provide 
> 
>    kernel-modules = <kernel version> 
> 
> However, some existing kernel module packages - particularly from the external
> livna repository - do not have this special require, but instead one that is
> named "kernel-modules-for-kernel". 

Guess what -- Livna/RPM Fusion removed the "Provides: kernel-modules" on purpose many moons ago to fix errors like this:

> Transaction Check Error:
> file /lib/modules/2.6.27.12-170.2.5.fc10.x86_64/extra/nvidia/nvidia.ko from install of kmod-nvidia-2.6.27.12-170.2.5.fc10.x86_64-180.25-1.fc10.x86_64 conflicts with file from package kmod-nvidia-2.6.27.12-170.2.5.fc10.x86_64-180.22-1.fc10.1.x86_64

Those show up again now due to the patch that was mentioned in #1. Request to revert this patch filed as Bug 482893.

Comment 4 Hans Ecke 2009-01-28 20:58:52 UTC
Thorsten, how do you fix the bug reported on top? Its fine that you want to remove your transaction check error. But you did not produce an alternate solution to this bug. 

What is worse - an unusable system or a yum error?

Comment 5 Thorsten Leemhuis 2009-01-29 05:43:06 UTC
(In reply to comment #4)
> Thorsten, how do you fix the bug reported on top?

RPM Fusion since it's start always had new kmods for new kernels withing hours, most of the time within an hour. That should do the trick.

> What is worse - an unusable system or a yum error?

A system that doesn't update to the latest kernel as that kernel might fix security problems.

But if people want that I#d suggest someone updates this plugin to do what you want. I haven't looked at the code; might be easy to do: Just don't mark kmods what provide "kernel-modules-for-kernel" as install

Comment 6 James Antill 2009-01-29 14:06:32 UTC
> RPM Fusion since it's start always had new kmods for new kernels withing hours,
> most of the time within an hour.

 Atm. it takes upto 48 hours for all the mirrors to sync. ... but even if this was perfect the above implies that the kernel is a normal package and once upgraded you can't run the older version again. Which is exactly the opposite of how the kernel package works.

> Just don't mark kmods what provide "kernel-modules-for-kernel" as install

 As I said, I've already done this upstream (which is why this BZ is closed) ... but calling these new things "kmods" when they won't work the same way as are current kmods, which use the kmod plugin, is going to cause a lot of confusion when they break.
 So again, I ask, "Can you rename these new things to not be called kmods."

Comment 7 Thorsten Leemhuis 2009-01-29 14:41:28 UTC
(In reply to comment #6)
> > RPM Fusion since it's start always had new kmods for new kernels withing hours,
> > most of the time within an hour.
>  Atm. it takes upto 48 hours for all the mirrors to sync.

Correct -- but that's a general problem for RPM Fusion and not specific to kmods. Hence I tried to get a discussion started to find a general solution (and where to apply it), but nothing came out of it yet :-(
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html

> ... but even if this
> was perfect the above implies that the kernel is a normal package and once
> upgraded you can't run the older version again. Which is exactly the opposite
> of how the kernel package works.

You afaics didn't get what I tried to explain, as running the older kernel with the older kmod-foo-$(uname -r) (which stays installed) is possible; it's even possible to ship updated kmods for non-current kernels in the repo. That's not possible with the older kmod-standard without special plugins.

Maybe it might be easier if you just look at a few kmods in RPM Fusion; that will likely explain it quicker and better then I can do it here. If you have question feel free to bug me in #fedora-devel as knurd (preferred during European (UTC+1) evenings).
 
> > Just don't mark kmods what provide "kernel-modules-for-kernel" as install
>  As I said, I've already done this upstream (which is why this BZ is closed)

Ohh, I thought you reverted the whole patch; but seems you just reverted a part of it. Yes, it might just work now. 

> ... but calling these new things "kmods" when they won't work the same way as
> are current kmods, which use the kmod plugin, is going to cause a lot of
> confusion when they break.
>  So again, I ask, "Can you rename these new things to not be called kmods."

No, as that would break a lot of packages and docs in the Fedora/RPM Fusion world. That's unacceptable. 

I also see no need for it. With your changes things might just work now as   Hans would like them to work. But if it helps we can add a "Provides: kmod2" or something like that.

Comment 8 Thorsten Leemhuis 2009-01-29 14:43:40 UTC
(In reply to comment #7)
> If you have
> question feel free to bug me in #fedora-devel as knurd (preferred during
> European (UTC+1) evenings).

BTW, maybe it would be good for all us to sit down and discuss what you guys plan for RHEL6. The current kmod stuff in RPM Fusion has a lot of improvements over the one that was the base in Fedora for RHEL5, thus it might be in the interest of RH to at least look at it and maybe use parts of it for RHEL6

Comment 9 James Antill 2009-01-29 15:03:34 UTC
> You afaics didn't get what I tried to explain, as running the older kernel with
> the older kmod-foo-$(uname -r) (which stays installed) is possible;

 Yeh, ok, I hadn't read the entry in the other BZ when I replied in this BZ (gah).

 How do old "new kmods" get removed?

> BTW, maybe it would be good for all us to sit down and discuss what you guys
> plan for RHEL6.

 Well we don't support anything but yum, so I'd guess we'd continue using what we've been using for RHEL-5 ... but there isn't a packaging committe that gets veto over new packages, so I also won't be shocked if some group releases a "new kmod" style package either.

Comment 10 Thorsten Leemhuis 2009-01-29 15:31:19 UTC
(In reply to comment #9)
> > You afaics didn't get what I tried to explain, as running the older kernel with
> > the older kmod-foo-$(uname -r) (which stays installed) is possible;
>  Yeh, ok, I hadn't read the entry in the other BZ when I replied in this BZ
> (gah).

np

>  How do old "new kmods" get removed?

They have a hard dep on the kernel -- thus yum automatically removes them when it removes old kernels :-)

> > BTW, maybe it would be good for all us to sit down and discuss what you guys
> > plan for RHEL6.
> Well we don't support anything but yum, so I'd guess we'd continue using what
> we've been using for RHEL-5 [...]

Well, what you guys do with RHEL6 is up to you, but I guess a lot of people would be glad if some of the kmod improvements (like akmods -- something like dkms) from RPM Fusion would find their way into RHEL6...


Note You need to log in before you can comment on or make changes to this bug.