[WBEL-devel] Heads up on RHEL Update2 Beta

[Joe Brouhard]

> You know, the more I ponder this, I might change my mind....
>
> In theory, the day you have a release (let's say update2), any machine
> that has been kept updated will be the same as a machine installed from
> the new ISOs.  Furthering this thought, if you have problems with update2,
> you will have the same problem with the updates (excluding installer
> issues)...
>

In theory, I would agree.  However, I make it a point not to apply updates
unless they're critical and they're known fixes.  For example, my
mailserver (nicknamed Diablo, cause it's a dual 333Mhz box) has a
heavily-customized postfix and courier-imap packages that include mysql
support and a few other features.  The updated packages that get sent out
won't work on my mail system, and as thus, I'd have to re-build the RPMs
with proper support.  Makes for keeping the mailserver up to date a little
problematic, but nontheless, it can be done.

> Keeping the 3.0 images are good from just a historical standpoint.  Images
> beyond that should probably overlap for a defined period (to verify that
> the new installs work), but after that can probably be removed leaving 3.0
> and 3.newest.
>

This point, I agree wholeheartedly.  Keep older packages for XX weeks, and
then remove them *OR* put them in a separate archive (some ISO or
something?0

> I'm still wavering on the idea of a re-spin for updates that don't provide
> more install-time hardware support.  For people buying CDs maybe working
> on an "updates" CD that has the yum headers, etc. on it would make sense?
> Yum supports the an option to specify a alternate config file.  That could
> probably be used to just do a "yum update" from the CD.  A lot less work
> than re-spinning the whole distro, and the narrowband users still can
> benefit from not having to download a bunch of updates post install.
>

I'm probably not understanding the concept of 're-spin' correctly, but..

I'd make a single Install set.  Then apply updates on the fly (i.e.
download them).  yes, this creates a bandwith hog on the mirrors, but My
suggestion would be that on the next set, set the YUM repositories to go
to a round-robin?  I know this has been done before (i'm no expert at
this... but I am a fan of the idea of having 'round-robin' yum
repositories so that there is one universal location that a user can 'yum'
to, but that location then sends the request to the fastest mirror it can
find).



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