[WBEL-devel] Heads up on RHEL Update2 Beta

[William Hooper]

John Morris said:
> On Tue, 6 Apr 2004, William Hooper wrote:
>
>> It looks like it might be a good idea to start planning a re-spin to
>> pick
>> up the driver updates (to make install easier):
>
> Yup.  I'm hearing tales of up to 250 packages changed from the base 3.0
> release.  Should still be doable in a reasonable timeframe even if I won't
> have the big Xeons this time.

So far the list I have seen (stop me if you are on the Taroon-list):
http://www.redhat.com/archives/taroon-list/2004-April/msg00083.html

And rhn-applet should probably be added to the list for WBEL :-)

> Been pondering the longterm requirements more as I settle into this for
> the long haul.....  Here are my thoughts, if anyone sees any obvious brain
> damage whack me, ok?
>
> As the updates roll on over the years, I figure I need to keep a partition
> for each supported version/platform, keep each up to date and use that to
> build the next update on, then reinstall (only real way to ensure nothing
> survives from the previous packages) with it for future errata.

Time to invest in VMWare?  Not sure if it handles AMD64 yet.

> Since it would be prudent to figure on needing at least 20GB to respin for
> 3.0 and add 5-10 with each successive version that pretty much means a
> dedicated 200G drive can handle it.
>
> Then there is the question of how to handle the respins on the main site
> in a way to minimize the burden for the mirrors.  The best idea I have had
> so far is to make this respin 3.1 and create a new top level, thus:
>
> delete 3.0-RC1
> 3.0-RC2
> 3.0
> 3.1
> contrib
>
> Then make 3.1/en/updates and 3.1/en/obsolete-updates links back to the 3.0
> tree.  But will rsync handle that without just duplicating the files on
> the mirrors?  It would handle a symlink but would up2date (guess it really
> depends on the configuration on the mirror) like that?  Or should up2date
> just continue to point at the 3.0 directory for updates, making a symlink
> safe?

Making a distiction between 3.0, 3.1, 3.x for errata is probably not going
to make sense, because only one errata package will be released.  Once all
the new updates go into the 3.1 tree no one will want to use the 3.0 tree.
 Up to this point (and IIUC this should be true for update2), just
installing the errata will get you up to the current level, so pointing to
one repo for updates should do the trick.  For that matter the version
number reported doesn't really change:

[whooper@token whooper]$ cat /etc/redhat-release
Red Hat Enterprise Linux WS release 3 (Taroon Update 1)

This way if you have a copy of the original ISOs you can still get up to
update1 just by using up2date.

> Either way, links are the only way to tackle the problem, since at two
> respins per year per base version that is a boatload of saved storage.
>
> Then there is the question of how many versions to plan on keeping online.
> The base 3.0 version probably needs to stay up for at least the 5yr
> availability of errata, but does a whole tree+iso set for 3.1 need to
> remain when 3.8 is available?  How many point revisions need to be
> available?  I'm inclined to be a little conservative and say at least two.
> As in 3.1 stays until 3.3 appears and has had some time to be declared
> good.

One of the reasones that RHEL went to 4 CDs is so that the first CD would
have room to allow for updates.  When update1 was released the only ISO
that changed was disc1.  Unfortunately I'm told that this won't be the
case in update2.  With WBEL it would probably make sense from a time
standpoint to just do re-spins when new hardware at install time is
supported.  I'm not sure if it would make sense from a bandwidth
standpoint, however.  The idea of keeping two 3.x ISO sets plus the 3.0
ISO set makes sense to me.

-- 
William Hooper