[WBEL-devel] Heads up on RHEL Update2 Beta

[Joe Brouhard]

Just my two cents, but...:

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

Looks like RedHat's structure as well.

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

IMNSHO, Older packages should be removed or placed in a "archive" area of
some sort.  Some of the mirrors I see keep track of their packages by
putting them into a folder that correlates with the version number of the
product.  But if we don't have a LARGE repository to put this stuff on,
Then I'd say lets keep two, maybe three versions up, but no more.

I'm probably not making sense here, since I have yet to have my daily
caffiene intake. <G>

> 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'd keep only two prior revisions, but keep all previous packages?

Better yet:  the YUM repositories should only keep the two most recent
trees only.  If you keep any further back, there's the chance some people
out there are going to end up using obsolete packages and/or bug-ridden
packages.  I don't think it'd be a good idea to keep anything past the
previous 2 releases.  Archive the ISO's (ANd packages as ISO images), but
i wouldn't keep the packages residing on the hard drive.. Not sure if the
package v iso idea will save space or not... never really tried it.

-- 
Joe Brouhard
Chief of Information Services
Kansas City Open Source Consultants
jbrouhard@kcosc.com