Re: A record number of breakages?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Michael Wiktowy wrote:
Rodd Clarkson wrote:


On Wed, 2005-08-17 at 15:44 -0400, Horst von Brand wrote:



Mark McLoughlin <markmc@xxxxxxxxxx> 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

--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list

[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]