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