[WBEL-devel] Heads up on RHEL Update2 Beta

[Milan Keršláger]

On Tue, Apr 06, 2004 at 07:17:44PM -0500, John Morris wrote:
> 
> 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.  So that
> means something like this:
> 
> 3.x - i386
> 3.x - amd64 (possibly, depends on when I upgrade the box at home)
> 4.x - i386
> 4.x - amd64
> 5.x - i386
> 5.x - amd64

You don't need extra partitions. All is able to live in chroot
environment without need to reinstall base system. With yum this is easy
to check if all updates/packages are in place (see list option).

If your build system is AMD64, you are able to build full clean i386
system in i386-only chroot tree and vice versa (AMD64 build needs clean
x86_64 tree with no i386 stuff).

Compilation does not depend on current (running) kernel.

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

There is no real reason to waste space like this. RH's build cluster is
in chroot environment too (there was posts in devel list in the past).

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

There is no need to make 3.1 when Red Hat itself has none and 3.0 +
updates is 3.1 then. Just respin ISOs like RH does (ok, as RH will do
after final U2).

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

I see no real reson to maintain 5+ versions when all are the same
(except installation ISOs). Who needs obsolete ISOs?

Just leave updates in same place and remove old ISOs. 

-- 
                        Milan Kerslager
                        E-mail: milan.kerslager@pslib.cz
                        WWW:    http://www.pslib.cz/~kerslage/