RFC: best way to fix the regular yum dependency problems with add-on packages from 3rd party repositories

David Timms dtimms at iinet.net.au
Sat Aug 2 14:47:09 UTC 2008


Thorsten Leemhuis wrote:
>> $ sudo yum update
>> [...]
>> Resolving Dependencies
>> --> Running transaction check
>> ---> Package kmod-nvidia.i686 0:173.14.09-5.lvn9 set to be updated
>> --> Processing Dependency: kmod-nvidia-2.6.25.11-97.fc9.i686 = 
>> 173.14.09-5.lvn9 for package: kmod-nvidia
>> --> Running transaction check
>> ---> Package kmod-nvidia-2.6.25.11-97.fc9.i686.i686 0:173.14.09-5.lvn9 
>> set to be updated
>> --> Processing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686 for 
>> package: kmod-nvidia-2.6.25.11-97.fc9.i686
>> --> Finished Dependency Resolution
>> kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686 from livna has 
>> depsolving problems
>>   --> Missing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686 is 
>> needed by
>> package kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686 (livna)
>> Error: Missing Dependency: kernel-uname-r = 2.6.25.11-97.fc9.i686 is 
>> needed by
>> package kmod-nvidia-2.6.25.11-97.fc9.i686-173.14.09-5.lvn9.i686 (livna)
> 
> I'd like to find a solution to solve this problem (which is *not* 

I got the impression that this is exactly what --skip-broken is for; yet 
it either doesn't get all cases, or isn't enabled by default. IMHO it 
sh/c/ould go further. Eg. during a yum update, every package that is
- available
- non-conflicting
- non-dependency breaking
- is actually downloadable/ed
should get updated when yum is using Fedora  default yum config.

eg: So in the inter-related repo problem, the user would still get that 
security update for firefox installed, even though the new kernel 
doesn't have a matching nvidia yet {or vice-versa}. The yum/PK summary 
should simply state:
installed 27 packages: x y z etc
3 packages are not currently downloadable: a b h
2 packages have conflicting requirements h k
leading to 7 packages not being installed at this time. These packages 
will be checked again at the next update. [ps. PK shouldn't keep 
informing me that there is updates available if the remaining 'to do' 
set can't resolve !]

In this case RF shouln't care when they make a new kmod available {ie 
can make it early}, and F wouldn't care when they release a security 
update, since only specific conflicting packages will not get 
immediately updated at the next update, rather than the current 
situation where conflict/deps/download problems can lead to long term 
inability for yum to do it's job.

Does this at least make logical sense, even if it might be difficult to 
achieve ?

DaveT.




More information about the fedora-devel-list mailing list