Bug 482893 - please revert the fedorakmod changes that were requested in bug 462099
Summary: please revert the fedorakmod changes that were requested in bug 462099
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: yum-utils
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Seth Vidal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-01-28 18:15 UTC by Thorsten Leemhuis
Modified: 2014-01-21 23:07 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-28 19:23:26 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Thorsten Leemhuis 2009-01-28 18:15:47 UTC
Users of RPM Fusion suddenly run into problems 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
( longer report http://fpaste.org/paste/2396 )

Disabling the yum-plugin fedorakmod fixed this.

I found Bug 462099 upon upon further investigation. That change done my James is responsible for this, as todays kmod packages as provided by RPM Fusion are meant to be updated like a any regular package -- but fedorakmod since the change from Bug 462099 marks kmod packages as as installonly (like kernel, kernel-devel, ....). That leads to this error, hence please revert it. 

Maybe it even would be the best to remove yum-fedorakmod completely from Fedora (something should obsolete it then, to make sure people don't run into problems like the one above) -- there are no kmods in fedora, hence shipping a plugin like this is better left to the repo that actually provides kmods.

Comment 1 James Antill 2009-01-28 19:23:26 UTC
 Ok, I will ... but can you also name them != kmod* ... it's just confusing to have them named the same thing as something else that works differently. Also I have to wonder how these new kernel module packages work ... you can't be using a stable ABI, because there is none. So do they just work/not-work depending on which of the N kernels that are installed is booted?
 This just screams that we're going to get bug reports everytime someone updates *sigh*.

Comment 2 Hans Ecke 2009-01-28 21:01:48 UTC
I hope I'm not spamming too much here. If you revert the solution to bug#462099, how _are_ kernel module packages supposed to work? Does that just get me back to square one?

Comment 3 James Antill 2009-01-28 22:08:44 UTC
Well if rpmfusion produces kmods that don't work, there's little we can do about it ... as I said I think if they change the name of the packages I think it will reduce confusion and have the users tell them and not us when it breaks. Apart from that I do not know.

Comment 4 Thorsten Leemhuis 2009-01-29 05:50:04 UTC
(In reply to comment #1)
>  Ok, I will...

many thx

> but can you also name them != kmod* ...

Definitely: No. I'm upstream for kmodtool and Fedora chose to not use it anymore. Hence kmodtool and kmods were developed further and used somewhere else. Hence things changed over time -- just like HAL, PA and hundreds of other packages change and packages that depend on them with them. 

> Also I have to wonder how these new kernel module packages work...

kmod-foo are just meta-packages these days that track in the latest kmod-foo-$(uname -r)  packages; those actually contain the kernel modules. That makes them work like normal packages -- hence they work without special treatment in yum, smart, apt, anaconda, which was one of the reasons for the change. It also allows to get modules for older kernels out to the users.


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