SCIENTIFIC-LINUX-USERS Archives

June 2011

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Stephen John Smoogen <[log in to unmask]>
Reply To:
Stephen John Smoogen <[log in to unmask]>
Date:
Fri, 24 Jun 2011 10:21:23 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (39 lines)
On Fri, Jun 24, 2011 at 06:51, Lamar Owen <[log in to unmask]> wrote:
> On Thursday, June 23, 2011 02:24:43 PM Stephen John Smoogen wrote:
> [snip good info]
>> Other reasons are similar things.. say the upstream beta had version
>> 1.0.1-2 but it turns out that it breaks scripts or something and they
>> need to put in final version 1.0.0-2. The beta tester will have a
>> "newer" version than what was in the final release.
>
> The difficulty with packages with identical NEVR but different contents is the problem 'yum distro-sync full' was meant to solve.  While distro-sync is available in yum 3.2.29, the 'full' option (which compares package checksums and issues a 'yum reinstall' for packages that are installed with the correct NEVR but are different will get refreshed) requires a 3.4.x yum.
>
> A 3.4.x yum is (or should be by now) in the CentOS testing repo for CentOS 5; the patch to add 'full' might apply cleanly to yum 3.2.29 (current upstream 6.1 yum).
>
> So the process to 'upgrade' from a beta to the GA would involve installing the new release RPM with the repo info, and then issuing 'yum distro-sync full' which in theory with upgrade and downgrade as needed to get you in sync with the current repo state, and witht he 'full' option it will reinstall packages whose NEVR matches but whose checksums do not.
>

Thanks. I wasn't aware of that option. In most cases, this will fix
most problems. The only place it will not is where an rpm pre(),
post(), triggers(), etc was the area of the fix. A beta file may make
an entry in some config file, but not remove it, and the final version
may not make that entry nor remove one that was there before. And in
many cases, that extra entry may not cause problems except to some
poor Joe who had to use UUCP over infiniband via satellite uplink.

The key issue is how long it takes to find this problem versus doing a
clean install. When I was younger I had no problems with spending 2
weeks to find that a beta package removed an obscure symlink but the
fix doesn't put it back. Now adays, I find that if the problem can't
be replicated on a clean install that reinstalling all the systems and
reconfiguring them with puppet/cfengine/func/etc takes a lot less than
2 weeks and not as much stress. However your mileage will vary
depending on job, time, and/or milk of magnesia intake.

-- 
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren

ATOM RSS1 RSS2