[rhelv6-beta-list] update RHEL6b2 to RHEL final

[Nico Kadel-Garcia]

On Tue, Oct 19, 2010 at 8:56 AM, John Haxby <jch at thehaxbys.co.uk> wrote:
>
>
> On 19 October 2010 13:10, Simon Matter <simon.matter at invoca.ch> wrote:
>   and I wrote:
>>
>> > It is entirely possible that RHEL6-final uses some rpms that are older
>> > than
>> > the ones that were in the beta release because the beta release ones
>> > were
>> > too buggy, incompatible and broken.   If you do a yum upgrade you'll
>> > leave
>> > those buggy, incompatible and broken RPMs in place.
>>
>> Good point! Of course that's easily to be checked with some lines of bash
>> script, simply compare the RPM versions of RHEL6-final against the
>> upgraded installation and you'll see if something need downgrading.
>>
>
> You  would like to think so wouldn't you?
>
> I've got someone here trying to do an anaconda upgrade from one beta to
> another and it's not working (some python exception).  Now, while I think
> it's a problem specific to this particular person and his fingers, I can't
> be sure that the old version of anaconda hasn't done something that's
> preventing the anaconda upgrade.

"Don't Use Anaconda(tm)".

As useful as it was as a basic installer, it's become a very awkward
tool over the years. In many cases, it's far cleaner to simply use
Anaconda's '%pre' option to run your own installer, especially with a
tarball image, because anaconda's interactions between configuration
settings for disks and network are far less flexible than a normal
setup script.

It's non-standard for RHEL installations, but it's a lot faster and
uses a lot less bandwidth for cluster installations. I've been using
it to redeploy clusters and have fully defined test environments,
without having to rewrite kickstart operations, for years. Unwrap the
tarball, chroot to it, make changes, exit the chroot, then bundle the
new tarball. Voila, new date stamped OS image.

> You could argue that you're not going to do an anaconda upgrade so there's
> no problem.  And you'd be right.  Right up until the point where you try to
> log a support call because something weird has happened and you don't know
> what and it turns out that it was because whatever it was that broken
> anaconda upgrade was something weird that broke something else ...

Well, these are dev installations. That's what they're for. The
"forward port to different OS" trick shouldn't be done with anaconda
because of the potential for just such confusion.

> I also recall, some time ago and with some embarrassment, that an RPM I
> wrote managed to break it's configuration in such a way that upgrading to a
> fixed one wasn't possible and reverting to the older one wasn't possible
> either even though it mostly worked.   Fortunately it never made it into the
> wider world, but it was very annoying and embarrassing nonetheless.

Hee-hee. You've my sympathies. Take a good look at the history of
package renaming and obsolescences for examples of such issues. ecj
and eclipse-ecj from RHEL 5 particularly come to mind. It happens to
everyone.