On Mon, 2002-12-23 at 16:53, R P Herrold wrote: > OK -- I admit it -- I am excited. > oh god - phoebe not working with yum A LOT of effort will be involved to make it work nicely and sanely. I'm working on it. I upgraded my laptop to phoebe recently so I could do just that. I'll have *something* soon, but my deadline is by the time TNV comes out and I think I have a little more time to go. > [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 ------- right - this will SO not work. a lot of the rpm calls have changed and so I have to go through and modify most of the code and redo how deps resolution works b/c of the way transaction sets and dep sets are being handled now. > > so: On a post 8.0 beta, yum is indeed well and truly not > working. yep, no doubt. But I coulda sworn I told y'all this, this morning :) > > 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. oh the pain the humanity, the pain. > 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. > ok this I agree with - we should monitor the space available for writing out the cache data, having said that I don't know how sanely that can be handled considering that 1. we don't know the compressed size of the rpm file, 2. we can only check to see what the most immediate download is going to do in terms of filling up disk space. I'm not sure of a good way of determining how much disk space we need when we don't have any real idea of the size of the files. we could base it off of the size in the hdr files, sure, but that is going to be double or greater the actual size of the rpms - that will return MANY false positives on out of disk space > 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. I think I know how this will need to be done - but it isn't trivial. 1. integrating the comps.xml stuff will make some of this more doable 2. making a comps group that is something like "rpm upgrade" so you can do things like pull in all of the prereqs etc. however, at some level the packages are going to have to know about the deps of rpm 4.2 on a newer kernel, etc 3. possibly special-casing rpm upgrades so that they are handled differently than everything else - something I don't want to have to do if we don't have to but might become necessary. right now my game plan is: - grok rpm-4.2's python modules more fully - sort out how best to do the dep handling - make these work nicely in yum - clean up some of the classes and steal some stuff from up2date and anaconda Once I have the same functionality created as was in rpm404 yum then: - comps.xml support - figure out what it will take to make rpm 4.[0|1] -> rpm 4.2 migrations work. - work on additional interfaces to yum. but in the most extreme immediate sense I am going to: visit with my parents and little brother enjoy the holidays a little work on this stuff late at night whilst the others are sleeping. -sv
