[CentOS] rpm --freshen issue (was: Re: Caught between a Red Hat and a CentOS)

David Fix davidf at mrxfx.com
Wed Oct 21 14:11:26 UTC 2009

Gotcha. :) Sorry about that. :) 

David Fix 

----- Original Message ----- 
From: KFisler at lakelandcc.edu 
To: "CentOS mailing list" <centos at centos.org> 
Sent: Wednesday, October 21, 2009 7:53:31 AM 
Subject: Re: [CentOS] rpm --freshen issue (was: Re: Caught between a Red Hat and a CentOS) 

The problem with such a loop is that only one pkg is the arg to each invocation of the rpm command. So if there are any dependencies for a particular invocation, nothing will be installed. 

	From: 	David Fix <davidf at mrxfx.com> 
	To: 	CentOS mailing list <centos at centos.org> 
	Date: 	10/21/2009 07:32 AM 
	Subject: 	Re: [CentOS] rpm --freshen issue (was: Re: Caught between a Red Hat and a CentOS) 
	Sent by: 	centos-bounces at centos.org 

Sorry, don't have time to read the whole thread (busy day!), so please excuse me if I just add to the noise, but this may work for you (at a bash prompt): 

for x in *; do rpm --freshen --repackage $x; done 

If it's not what you're looking for, I apologize in advance. :) 

David Fix 

----- Original Message ----- 
From: "ken" <gebser at mousecar.com> 
To: "CentOS mailing list" <centos at centos.org> 
Sent: Wednesday, October 21, 2009 5:12:14 AM 
Subject: [CentOS] rpm --freshen issue (was: Re: Caught between a Red Hat and a CentOS) 

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 

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 
if {there are dependencies} 
then for {each dependency} {upgrade package} # yep, recursion 
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 

Benjamin, thanks for your constructive response. Any further such (from 
you or anyone else) will be much appreciated. 


> Alternatively, use 'createrepo' to create a Yum repository of the RPMs 
> and use yum to handle it for you. 
CentOS mailing list 
CentOS at centos.org 

CentOS mailing list 
CentOS at centos.org 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos/attachments/20091021/8cf47613/attachment.html>

More information about the CentOS mailing list