[Yum] yumming it up with Phoebe

R P Herrold herrold at owlriver.com
Mon Dec 23 23:10:22 UTC 2002


On 23 Dec 2002, seth vidal wrote:

> On Mon, 2002-12-23 at 16:53, R P Herrold wrote:
> > OK -- I admit it -- I am excited.

> 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.

<smile>

> right  - this will SO not work.

<snip -- yup -- smile>

> > 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 :)

Oh, well and truly agreed -- but as I said at the start, I am 
excited about yum -- and had a host begging for abuse.  I 
don't let them linger, and they are revived soon, anyway.

btw: That second attempt on the RHL 8.0 ran out of room as
well -- I did not catch that it was rpm space required rather
than overflowing the download cache space:  I cleaned house [/
and /usr, rebuilt the rpmdb], put a stitch in that cut over
his right eye, and sent the kid back into the ring:

[root at winston rpm]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda2               350007    245394     86540  74% /
/dev/sda1                31079     16297     13178  56% /boot
none                    257004         0    257004   0% /dev/shm
/dev/sda5              1004024    691412    261608  73% /usr
/dev/sdb5              1007736    335080    621464  36% /var/cache/yum
[root at winston rpm]#

So the bare update transaction set was 335M for this host.
 
> oh the pain
> the humanity, the pain.

> 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.

Ehhh??  I _think_ the expanded size is already in the header:

[root at ftp i386]# ls -al zlib-devel-1.1.4-1tr.i386.rpm ; rpm \
	-qp --qf '%{name}\t%{size}\n' zlib-devel-1.1.4-1tr.i386.rpm
-rw-rw-r--    1 herrold  herrold     66009 Nov 27 16:50 \
	zlib-devel-1.1.4-1tr.i386.rpm
zlib-devel      163241
[root at ftp i386]#

> > 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

I dislike this comps based approach for it complicates
yum-arch enormously -- right now, a simple cron process and an
arbitrary locally maintained set of local packages can be
trivially added as an archive to yum archive coverage -- add a
new stanza to yum.conf at the clients, and it is used.

The re-visits to genhdlist, and comps over the last 4 or 5 RHL
releases, experienced by the 'build your own updated ISO'
pieces -- Tony Nugent's 7.x variant comes to mind -- indicate
that building against stability in comps has been unprofitable
in the past.  The xml-ization in ks.cfg is something I've 
RFE'd in RH's Bugzilla.

I was sketching out scriptable yum.conf tools based on our 
discussion a couple weeks ago -- batch, and X based -- earlier 
today.

The fnal archive aches for this level of easy host management,
and it looks as though it is largely on the path of completing
a transition away from autorpm in that regard.  Nice work,
Troy  I want to know about the PXE booting and install hooks I 
see there as well. <smile>

> 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

Same issue as number 1 -- but the rpm-4.2/kernel dependency is
properly a major change, and yum will really need to be aware
of to and from version (similar to the earlier transition into
rpm-3.0.4) and be quite careful and conservative there anyway. 

-- Thus my suggestion of a stepwise approach, doing the
smaller and 'easier' [easier == not on an exception list
including kernel, glibc, rpm] subsets first, to the
un-qualified 'upgrade' and 'update' option (which, with a
switch in archive reduce to the same case.)

> 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.

> 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.

Sounds like good priorities -- family, relaxation, and more 
relaxation.

Thanks for the efforts, Seth -- enjoy the week.

-- Russ herrold




More information about the Yum mailing list