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

[David Timms <dtimms iinet net au>]

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.