[CentOS] rpm --freshen issue

[ken]

On 10/21/2009 10:03 AM Barry Brimer wrote:
> 
> On Wed, 21 Oct 2009, ken wrote:
> 
>> On 10/20/2009 12:15 PM Benjamin Franz wrote:
>>> ken wrote:
>>>> Okay, here's one. Maybe someone here can figure it out.
>>>> Upgrading from 4.5 to 4.5.  From a 4.6 ISO I copied all the RPMs into a
>>>> directory... let's call it c:/install :).   Now the oracle dba has
>>>> strict parameters on what versions can be installed and which can't.
>>>> The rpms in c:/install meet those requirements.  In addition, since this
>>>> is a production machine, it can be down at most for one day.  So all I
>>>> want to do is upgrade what's currently on the system.  Moreover, if
>>>> something horks, I want two chances to back out (the second being asking
>>>> the backup guy to put the system back to yesterday).  The command to do
>>>> this would be
>>>>
>>>> rpm --freshen --repackage *
>>>>
>>>> run in that crazy c:/install directory (or what the redhat guy called, a
>>>> "folder").  This command runs fine for one file which has no
>>>> dependencies (i.e., change '*' to a specific rpm).  It also upgrades
>>>> three or four co-dependent rpms if they're narrowly specified.  But if
>>>> the file/rpm spec is '*', rpm complains about two missing dependencies
>>>> and stops.
>>>>
>>>> Yeah, this directory contains 1507 rpms (IIRC)... which is a lot, but it
>>>> should still work.  This is Linux, after all.  And there's plenty enough
>>>> memory and cpu to handle it.
>>>>
>>> Running
>>>
>>> rpm --freshen --repackage *
>>>
>>> for 1500+ rpms  probably exceeds the maximum character length for some
>>> part of the system after expansion of the '*'  by the shell.
>> That was my first suspicion too.  The redhat tech didn't bring that up
>> though.  (That doesn't mean I'm going to ignore that as a possible
>> workaround; the original conversation here was about tech support per
>> se.  Of course I'm still seeking ways to do the job.  And so thanks for
>> the suggestion.)
>>
>> I, too, recall reading some years back about a bash line length limit.
>> Back then, a long time ago, it was 2048 characters.  So I ran "echo *"
>> in that same install/ directory and the output included all 1507 files.
>> So the problem's not with a bash command line length limit, but still
>> pointing to the "rpm" command.
>>
>>
>>
>>> Try breaking it up into smaller chunks (say two or three hundred at a
>>> time). You can match subsets of the files using shell expansions like
>>>
>>> rpm --freshen --repackage [a-g]*
>>>
>>> and tweak the line for any dependency complaints manually.
>> This solution occurred to me also.  And right now it's a top contender
>> (along with another I'll mention shortly).  If the job environment were
>> different, I'd go with it.  But my boss is making me jump through a lot
>> of hoops for this project.  This upgrade from v.4.5 to v.4.6 needs to
>> happen in a single, specified day *and* my boss needs to know how long
>> it will take me to accomplish, this so the Oracle dba knows when he can
>> start to on what he's got to do for this upgrade.  And I have at most
>> fifteen hours (i.e., two working days) to come up with this fool-proof
>> plan.  Plus, I don't have a test box to try things out on.  But I've had
>> to do trickier stuff than this in the past with not dissimilar time
>> constraints, so though I should be taking extra boxers to work, I'm not
>> (yet).
>>
>> So what I was thinking of doing is scripting the solution you suggest
>> above.  But then, if I'm going to script something, I might as well
>> write a script that will take on the entire task wholistically.  I mean
>> something like this:
>>
>> ls -1 install/ > what-to-upgrade.list  # create package list
>> while read package | {upgrade package}  #just quasi-code here. Loop.
>> if {there's nothing to upgrade}
>>  remove pkg from what-to-upgrade.list
>>  log this
>>  continue
>> fi
>> if {there are dependencies}
>> then for {each dependency} {upgrade package}  # yep, recursion
>> fi
>> else [upgrade package}         # simplest case, just upgrade one pkg
>>
>> The {upgrade package} function would be fairly simple (I think):
>> - Find the correct package in the install/ directory (containing the
>> RPMs for v.4.6).
>> - Upgrade the 4.5 package with that correct 4.6 package.
>> - Confirm that the 4.6 is installed.
>> - Remove that package name from what-to-upgrade.list
>> - Log that this package has been upgraded.
>>
>> I already see some bogus stuff here, but I'm writing this on the fly.
>> Point is, it seems do-able, and probably within the time constraints.
>> And then, what are the alternatives?
>>
>> One, suggested by the redhat tech (about whom there's more news...
>> later), is to use up2date.  I read the manpage on it and it's pretty
>> vague.  I'm sure I have, but I don't recall using it before, so I can't
>> fill in the details which the manpage lacks.  Lastly, I don't see a way
>> to test up2date to see if it will work within my (dba's) specific
>> parameters.
> 
> If you add --aid on the end of your rpm command, and you are in the 
> directory with the rpms, it should solve any dependency issues for you 
> provided that the rpms that are needed are in the local directory.  If a 
> pendency is resolved by something that you later try to upgrade i *think* 
> rpm will just tell you that that particular package is already installed. 
> I could be wrong.  Either way .. try the --aid.  Also, don't forget that 
> you can add the --test flag to rpm to find out if rpm will work or not.
> 
> Hope this helps,
> Barry

Barry,

In fact I tried that at work today (at the suggestion of a redhat tech),
but no go.  I don't understand why.  According to the docs, it should...
but it simply didn't.  But you are correct about the --test option.
It's worked fine for days (at least :).  Good thing too, as I don't have
a development box to do any testing on.

Thanks for the reply though.  People on this list are really great folk.

Best,
ken