A record number of breakages?

Michael Wiktowy mwiktowy at gmx.net
Thu Aug 18 14:58:40 UTC 2005


Rodd Clarkson wrote:

>On Wed, 2005-08-17 at 15:44 -0400, Horst von Brand wrote:
>  
>
>>Mark McLoughlin <markmc at redhat.com> wrote:
>>    
>>
>>>On Tue, 2005-08-16 at 21:43 +0100, Paul wrote:
>>>      
>>>
>>>>I'm not sure if it's me or the build box, but today must go down as the
>>>>day with most number of packages borked in rawhide - there are tonnes
>>>>relying on libpixman and libcairo and if they're excluded, there are
>>>>still about that additionally have to be excluded as well!
>>>>        
>>>>
>>>	Here's a thought - if the daily rawhide report comes with a list of
>>>broken dependencies, it probably wouldn't take much for it to also
>>>include the yum command line needed to update everything not affected by
>>>the broken deps. Or yum itself could have a --exclude-broken-deps ...
>>>      
>>>
>>I'd vote for --shadow=SomePackageGlob, meaning "Install everything that
>>doesn't depend (directly or indirectly) on SomePackage" (modulated by the
>>usual --exclude=SomeJunk and ListOfStuff arguments). Methinks this would be
>>generally useful, not only for futzing around with rawhide, as this is
>>usually what you want (not just raw --exclude=ThisOrThat).
>>
>>Or else, "--install-whatever-you-can --i-know-what-im-doing
>>--yes-i-do-mean-it --just-doit-damnit" flags
>>
>>    
>>
>>>	Broken deps are always going to be a fact of life with rawhide - it'd
>>>be nice if didn't suck up too much time for people, though.
>>>      
>>>
>
>Why make this so confusing?
>
>Why not just have yum run as it usually does.  If all is good the all is
>good.  If there are broken dependencies, then yum could report that not
>all the updates could be installed and supply a list of updates that can
>be installed and updates that can't be (and why - presumably broken
>dependencies).  For here, yum would ask you would you like to install
>those updates that can be install and then assuming you do install them.
>
>This would be a much saner default IMHO.  For starters, it would mean
>that in situations where yum has a list of 30 or 40 updates (and
>presumably security updates amongst them) and there's a problem with
>just a single package, you still get most of the goodness (including
>security updates).
>
>There's not really any need to special flags since this seems like a
>pretty sane way for yum to run.  As long as it reports what wasn't
>installed so that people know that some packages haven't been installed
>(and why) then this would solve a lot of traffic on the list and make
>installing what packages that can be install much easier.
>
>
>Rodd 
>  
>

There was some discussion about this a year and a half back:
https://www.redhat.com/archives/fedora-test-list/2004-March/msg00999.html
and some earlier than that that I can't find in the archives.

I think that the conclusion boiled down to yum being a dependancy
*solver* not a dependancy *ignorer* and for the default operation to do
all of what the invoker intended or nothing at all (other than
outputting informative errors pointing to the problem ... something that
has imporved a great deal since then) so that they can be used sanely
and predictably in automated scripts.
I would like this functionality too but it does make a degree of sense
to do it outside of yum.

It is not hard (I managed to do it :]) to make a script that parses out
a list of all the available updates and tries to update them one at a
time. Yum will fail cleanly on the broken dependancy branches and
packages that were brought in via previous iterations. Not the most
efficient way of skinning the cat but it works. I suppose much better
methods could be used with the new yum-tools available but I haven't
looked into them yet.

/Mike




More information about the fedora-test-list mailing list