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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
