OK -- I admit it -- I am excited.
I pulled the Phoebe ISO's, mounted them on loopback, and built
a linkfarm to get all the rpm's into the same directory.
I built a yum-arch into the linkfarm with the -l option.
First I did it with a new Phoebe install and a locally built
yum:
[root@dhcp-94 dl]# yum update
Gathering package information from servers
Getting headers from: Red Hat Linux Phoebe base
Traceback (most recent call last):
File "/usr/bin/yum", line 24, in ?
yummain.main(sys.argv[1:])
File "yummain.py", line 144, in main
File "clientStuff.py", line 139, in rpmdbNevralLoad
File "clientStuff.py", line 130, in openrpmdb
AttributeError: 'module' object has no attribute 'opendb'
[root@dhcp-94 dl]# cat /etc/yum.conf
[main]
cachedir=/var/cache/yum
debuglevel=2
logfile=/var/log/yum.log
pkgpolicy=newest
[base]
name=Red Hat Linux Phoebe base
baseurl=ftp://ftp.victim.lan/pub/install/ftpinstall/
----------- snippet ends -------
so: On a post 8.0 beta, yum is indeed well and truly not
working.
Then, over on a RHL 8.0 box, I similarly updated my
/etc/yum.conf to point to the ftp Phoebe install server.
As it is going FROM rpm-4.1, it should work -- until it
updates rpm, at which time I expect it to fall over and die,
due to the rpm-4.2 opendb changes (As I read the code, it does
not hold the rpm helpers open, so they will get upgraded out
from under the running yum instance). The 'victim' client
machine is a tester, and so no tears if this happens.
It is happily cranking away, but I am a bit worried that it
will run out of room on the update -- I only have 500 M
available in /var/cache/
...
[update: ipchains.i386]
[update: mutt.i386]
[update: ed.i386]
I will install/upgrade these to satisfy the depedencies:
[deps: ttmkfdir.i386]
[deps: XFree86-libs-data.i386]
[deps: elfutils.i386]
[deps: pyxf86config.i386]
[deps: elfutils-libelf.i386]
Is this ok [y/N]: y
Getting pkgconfig-0.14.0-1.i386.rpm
Getting hotplug-2002_04_01-14.i386.rpm
Getting wvdial-1.53-8.i386.rpm
...
Getting ed-0.2-30.i386.rpm
Calculating available disk space - this could take a bit
<time passes>
Error: Disk space Error
You appear to have insufficient disk space to handle these packages
[root@winston cache]#
Rats ... So I tossed in a bigger drive and will retry:
[root@winston cache]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 350007 263412 68522 80% /
/dev/sda1 31079 16297 13178 56% /boot
none 257004 0 257004 0% /dev/shm
/dev/sda5 1004024 908552 44468 96% /usr
/dev/sdb5 1007736 20 956524 1% /var/cache/yum
[root@winston cache]# yum update
Thinking about this, obviously not ALL the binaries need to be
installed first -- I was able to pull onsies and twoies in,
in preliminary testing.
Presently the .hdr has the file size information; indeed, it
is using it to decide it cannot do the install. It does not
always do this checking -- I have had it pull and over-run
available /var/cache/yum/ space -- it probably needs an RFE to
decide if it can pull files earlier in the process before
actually pulling them.
Back to matters at hand, thinking about Seth's post of this
morning, and the issue raised for sysadmins with a mixed
userbase with RHL 8.0, and whatever the next version is
called, safely doing rpm-4.1 to rpm-4.2 upgrades is going to
be a challenge:
Could yum find a path of several transactions sets to
successively pull partial update sets in, being aware of
interim space limitations in the local /var/cache/ -- indeed,
one could hold off and do rpm (and the kernel supporting the
new RPM threaded lock model) in the last transaction set.
-- understanding that it is not a priority, has anyone taken a
stab at this?
-- Russ Herrold
