All FYI, short version: nothing too bad happened, but we aren't perfect ... yet :).
machine 1:
Completely up to date with "updates", maybe some updates-testing too.
machine 2:
Very much not upto date, probably not updated much since GA[1]. I
think this is a machine I tested my hacky iter-update code[2], so it's
possible that screwed something up.
machine 1
---------
I did "yum instD yum", and everything seemed to work fine but "yum
list" and "yum search" were going much slower than I thought they would
be, I eventually found out that at some point in the distant past I'd
put the following in yum.conf:
exclude=ajflkdsamlkasmflaksmfaslkmfadslkm
...don't ask me why I did that, I'm old :p. But removing that took the
times back from ~4secs down to the ~1.5secs area I'd assumed it would
be. This presumably means that those people with the scary all .i386
except glibc.i386 excludes are not going to win yet.
There are a couple of ways we can get solve this.
machine 2 (done a few hours after machine 1)
--------------------------------------------
Again, I did the "yum instD yum" ... the first time it hit a mirror
with 3.2.8, so I upgraded to that, and rm'd the cache. But this time it
wanted to install a _lot_ of stuff from rawhide, so I hit C-c.
It looks like pygpgme wasn't installed/uptodate, as I did yum install
pygpgme and it wanted to do a bunch of stuff (NOTE: yum-3.2.8 now)
however I had an idea and got 3.2.10 from rawhide via. yumdownloader and
did "yum inst ./yum-3.2.10*.rpm" ... but this just installed yum, and
yum worked fine afterwards.
We can probably repeat this test using Fedora 8 GA.
Then I did "yum up -y", this died due to "postgresql*.i386" and
"openoffice*.i386" old versions conflicting with the updated x86_64
versions. I did "yum remove 'postgres*.i386'" and then the same for
openoffice*.i386 and it then worked.
Post update I tried "yum remove '*.i386'", except that wants to remove
a huge pile of .x86_64 stuff ... maybe that's known.
Also worthy of note is that during the above full update it seemed to
take between 5-10 seconds for the "Total size/Download size" calculation
however this was for 450MB of stuff and iotop showed the disks doing
~30MB/s read IO, which implies it would be ~15 seconds ... so maybe it
seemed shorter than it was.
Now to be fair the transaction test check took minutes, but the delay
was particularly noticeable to me because I'd done -y ... so maybe it's
worth dropping that feature when people do that, then again it was
useful to see that it wasn't going to download anything.
I add this mainly because Seth was worried about how long doing the
check for this feature would take.
Another interesting fact was that when I was looking at memory usage in
top yum didn't get over 85MB RSS while doing the actual transaction.
[1] I think this might have been because yum-updatesd couldn't get past
the above multilib. problem.
[2] http://people.redhat.com/jantill/yum/yum-iter-update.py -- the basic
idea is you get a full list of updates, and if there are any try the
first on the list with "yum update -y X" ... then start again.
--
James Antill <[EMAIL PROTECTED]>
Red Hat
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
