[WBEL-devel] Heads up on RHEL Update2 Beta

[Johnny Hughes]

My whole take on this is:

RedHat only releases bug fixes and security updates to RHEL.  There are
no version upgrades without a bug or security reason.

So a respin of the install ISO, with all fixes incorporated is good...it
means a much faster install and much fewer updates after the original
install.

Up2date (or yum) will pick the proper updates (so long as the package
name versioning is correct) reguardless of wether you installed from the
orignal ISO or a respun ISO.  (Since the respins only include some of
the newer packages)

So, as William Hooper said, you only need one update section for all the
respins...and just keep the latest package there for each package
updated (from the original ISOs), just like you are doing now.

I would think you would only keep the current respins files in the OS
directory ( 3.0/en/os/i386/ ) on the mirrors .... and copies of the
original ISOs and the Latest respin ISOs.

If you wanted the respins to be a new version number (like 3.0.1 or 3.1
instead of 3.0 ... then just put a text file in the 3.0 directory that
says goto 3.0.1 and provide an updated /etc/yum.conf and
/etc/sysconfig/rhn/sources files that point to the new locations).

>From a GPL standpoint, the original source ISOs and the updates SRPMS
directory (and the obsolete-updates directory) meet all the
requirements.

-Johnny Hughes


On Wed, 2004-04-07 at 14:16, Joe Brouhard wrote:
> > 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).
> 
>