A record number of breakages?

[Jim Cornette]

Michael Wiktowy wrote:
> 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
> 

That sounds like the way I am updating through development. I use the 
output of available packages and throw the output into a script. I then 
find and replace this "---> Package" with "yum -y update" and replace 
"set to be updated" and "set to be installed" with a blank space using 
an editor. I then save the script and run it.
This is very slow with the present state of development. (Almost 24 hrs 
running)

---> Package cairo.i386 0:0.9.2-2 set to be updated
---> Package gnomemeeting.i386 0:1.2.1-5 set to be updated
---> Package evolution-data-server-devel.i386 0:1.3.7-2 set to be updated
---> Package gtkhtml3.i386 0:3.7.6-2 set to be updated
---> Package evolution-devel.i386 0:2.3.7-3 set to be updated
---> Package gnome-panel.i386 0:2.11.91-3 set to be updated
---> Package gnutls-devel.i386 0:1.2.6-1 set to be updated
---> Package gaim.i386 1:1.5.0-3.fc5 set to be updated
---> Package xmlsec1-gnutls.i386 0:1.2.8-3 set to be updated

becomes:

yum -y update cairo.i386 0:0.9.2-2
yum -y update gnomemeeting.i386 0:1.2.1-5
yum -y update evolution-data-server-devel.i386 0:1.3.7-2
yum -y update gtkhtml3.i386 0:3.7.6-2
yum -y update evolution-devel.i386 0:2.3.7-3
yum -y update gnome-panel.i386 0:2.11.91-3
yum -y update gnutls-devel.i386 0:1.2.6-1
yum -y update gaim.i386 1:1.5.0-3.fc5
yum -y update xmlsec1-gnutls.i386 0:1.2.8-3

Jim