Re: [CentOS] rpm --freshen issue
War is a failure of the imagination. --William Blake On 10/21/2009 10:27 AM Todd Denniston wrote: > ken wrote, On 10/21/2009 05:12 AM: >> On 10/20/2009 12:15 PM Benjamin Franz wrote: >>> ken wrote: > 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. > > > >> Benjamin, thanks for your constructive response. Any further such (from >> you or anyone else) will be much appreciated. >> >> Best, >> ken >> >>> Alternatively, use 'createrepo' to create a Yum repository of the RPMs >>> and use yum to handle it for you. >>> > > Ken, > please let me second the idea for using createrepo on the collection so that > you can then use yum to > resolve everything. > > Assuming "/install" is where the rpms are at and createrepo is installed from > base(at least on 5. it > is in base), running the following commands should get the system going: > > createrepo /install > cat >> /etc/yum.repos.d/quickupdate.repo << END_EOF > [expedient] > name=expedient update dir > baseurl=file:///install > enabled=0 > #assume the machine already has gpg key for all rpms you have > gpgcheck=1 > END_EOF > yum update --disablerepo=\* --enablerepo=expedient > > > > alternatively if the problem is not really the shell length, then > yum localupdate /install > or > yum localupdate /install/* > might work. > https://www.centos.org/modules/news/article.php?storyid=118#comment90 > http://fedoraforum.org/forum/archive/index.php/t-140404.html > Todd, I like your idea and love all the details you provide. I use yum at home (on the machine I'm hitting on now and one other one) and love it. One of the first things I did when I got handed this rh v.4.5 machine was to check for yum. It's not there. I looked around redhat's site for a version of it to run on 4.5, but couldn't find it. It did exist for 4.5, but for some reason my predecessor didn't install it. I'll hunt around for it some more, but if anyone knows a place on the web, a link would be great. Until then, it looks like I might have to use up2date. For some reason I don't feel a lot of joy in that prospect. Thanks for the great yum info. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] rpm --freshen issue
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 yo
Re: [CentOS] rpm --freshen issue
ken wrote, On 10/21/2009 05:12 AM: > On 10/20/2009 12:15 PM Benjamin Franz wrote: >> ken wrote: >>> >>> 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. > > Benjamin, thanks for your constructive response. Any further such (from > you or anyone else) will be much appreciated. > > Best, > ken > >> Alternatively, use 'createrepo' to create a Yum repository of the RPMs >> and use yum to handle it for you. >> Ken, please let me second the idea for using createrepo on the collection so that you can then use yum to resolve everything. Assuming "/install" is where the rpms are at and createrepo is installed from base(at least on 5. it is in base), running the following commands should get the system going: createrepo /install cat >> /etc/yum.repos.d/quickupdate.repo << END_EOF [expedient] name=expedient update dir baseurl=file:///install enabled=0 #assume the machine already has gpg key for all rpms you have gpgcheck=1 END_EOF yum update --disablerepo=\* --enablerepo=expedient alternatively if the problem is not really the shell length, then yum localupdate /install or yum localupdate /install/* might work. https://www.centos.org/modules/news/article.php?storyid=118#comment90 http://fedoraforum.org/forum/archive/index.php/t-140404.html -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] rpm --freshen issue (was: Re: Caught between a Red Hat and a CentOS)
Gotcha. :) Sorry about that. :) -- David Fix - Original Message - From: kfis...@lakelandcc.edu To: "CentOS mailing list" 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 To: CentOS mailing list 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-boun...@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" To: "CentOS mailing list" 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 (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 o
Re: [CentOS] rpm --freshen issue (was: Re: Caught between a Red Hat and a CentOS)
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
provi
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
To:
CentOS mailing list
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-boun...@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"
To: "CentOS mailing list"
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
(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
Re: [CentOS] rpm --freshen issue (was: Re: Caught between a Red Hat and a CentOS)
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"
To: "CentOS mailing list"
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
(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 su
