<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'><span>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):</span><div><br></div><div><span id="e8a48ce4-357a-4e6c-86c0-3e812a1a91ba"></span><font class="Apple-style-span" face="'Courier New', courier, monaco, monospace, sans-serif">for x in *; do rpm --freshen --repackage $x; done</font></div><div><br></div><div>If it's not what you're looking for, I apologize in advance.  :)</div><div><div><span id="e8a48ce4-357a-4e6c-86c0-3e812a1a91ba"><br>--<br>David Fix<br><br></span><br>----- Original Message -----<br>From: "ken" <gebser@mousecar.com><br>To: "CentOS mailing list" <centos@centos.org><br>Sent: Wednesday, October 21, 2009 5:12:14 AM<br>Subject: [CentOS] rpm --freshen issue (was: Re: Caught between a Red Hat and a CentOS)<br><br><br>On 10/20/2009 12:15 PM Benjamin Franz wrote:<br>> ken wrote:<br>>> Okay, here's one. Maybe someone here can figure it out.<br>>> Upgrading from 4.5 to 4.5.  From a 4.6 ISO I copied all the RPMs into a<br>>> directory... let's call it c:/install :).   Now the oracle dba has<br>>> strict parameters on what versions can be installed and which can't.<br>>> The rpms in c:/install meet those requirements.  In addition, since this<br>>> is a production machine, it can be down at most for one day.  So all I<br>>> want to do is upgrade what's currently on the system.  Moreover, if<br>>> something horks, I want two chances to back out (the second being asking<br>>> the backup guy to put the system back to yesterday).  The command to do<br>>> this would be<br>>><br>>> rpm --freshen --repackage *<br>>><br>>> run in that crazy c:/install directory (or what the redhat guy called, a<br>>> "folder").  This command runs fine for one file which has no<br>>> dependencies (i.e., change '*' to a specific rpm).  It also upgrades<br>>> three or four co-dependent rpms if they're narrowly specified.  But if<br>>> the file/rpm spec is '*', rpm complains about two missing dependencies<br>>> and stops.<br>>><br>>> Yeah, this directory contains 1507 rpms (IIRC)... which is a lot, but it<br>>> should still work.  This is Linux, after all.  And there's plenty enough<br>>> memory and cpu to handle it.<br>>>   <br>> <br>> Running<br>> <br>> rpm --freshen --repackage * <br>> <br>> for 1500+ rpms  probably exceeds the maximum character length for some <br>> part of the system after expansion of the '*'  by the shell.<br><br>That was my first suspicion too.  The redhat tech didn't bring that up<br>though.  (That doesn't mean I'm going to ignore that as a possible<br>workaround; the original conversation here was about tech support per<br>se.  Of course I'm still seeking ways to do the job.  And so thanks for<br>the suggestion.)<br><br>I, too, recall reading some years back about a bash line length limit.<br>Back then, a long time ago, it was 2048 characters.  So I ran "echo *"<br>in that same install/ directory and the output included all 1507 files.<br> So the problem's not with a bash command line length limit, but still<br>pointing to the "rpm" command.<br><br><br><br>> <br>> Try breaking it up into smaller chunks (say two or three hundred at a <br>> time). You can match subsets of the files using shell expansions like<br>> <br>> rpm --freshen --repackage [a-g]*<br>> <br>> and tweak the line for any dependency complaints manually.<br><br>This solution occurred to me also.  And right now it's a top contender<br>(along with another I'll mention shortly).  If the job environment were<br>different, I'd go with it.  But my boss is making me jump through a lot<br>of hoops for this project.  This upgrade from v.4.5 to v.4.6 needs to<br>happen in a single, specified day *and* my boss needs to know how long<br>it will take me to accomplish, this so the Oracle dba knows when he can<br>start to on what he's got to do for this upgrade.  And I have at most<br>fifteen hours (i.e., two working days) to come up with this fool-proof<br>plan.  Plus, I don't have a test box to try things out on.  But I've had<br>to do trickier stuff than this in the past with not dissimilar time<br>constraints, so though I should be taking extra boxers to work, I'm not<br>(yet).<br><br>So what I was thinking of doing is scripting the solution you suggest<br>above.  But then, if I'm going to script something, I might as well<br>write a script that will take on the entire task wholistically.  I mean<br>something like this:<br><br>ls -1 install/ > what-to-upgrade.list  # create package list<br>while read package | {upgrade package}  #just quasi-code here. Loop.<br>if {there's nothing to upgrade}<br>  remove pkg from what-to-upgrade.list<br>  log this<br>  continue<br>fi<br>if {there are dependencies}<br>then for {each dependency} {upgrade package}  # yep, recursion<br>fi<br>else [upgrade package}         # simplest case, just upgrade one pkg<br><br>The {upgrade package} function would be fairly simple (I think):<br>- Find the correct package in the install/ directory (containing the<br>RPMs for v.4.6).<br>- Upgrade the 4.5 package with that correct 4.6 package.<br>- Confirm that the 4.6 is installed.<br>- Remove that package name from what-to-upgrade.list<br>- Log that this package has been upgraded.<br><br>I already see some bogus stuff here, but I'm writing this on the fly.<br>Point is, it seems do-able, and probably within the time constraints.<br>And then, what are the alternatives?<br><br>One, suggested by the redhat tech (about whom there's more news...<br>later), is to use up2date.  I read the manpage on it and it's pretty<br>vague.  I'm sure I have, but I don't recall using it before, so I can't<br>fill in the details which the manpage lacks.  Lastly, I don't see a way<br>to test up2date to see if it will work within my (dba's) specific<br>parameters.<br><br><br>Benjamin, thanks for your constructive response.  Any further such (from<br>you or anyone else) will be much appreciated.<br><br>Best,<br>ken<br><br>> <br>> Alternatively, use 'createrepo' to create a Yum repository of the RPMs <br>> and use yum to handle it for you.<br><br></div></div></div></body></html>