Re: Re: upgrading 7.2+rawhide -> rh8.0 via grab

I wonder if we can make this entire thing simplified... Something that I was
doing to test GRABs dependancy checking was to comment out the lines
associated with doing the local check for provides. I wonder if GRAB ignores
everything local and just makes sure that 1) all packages have an update
canditate (and warn about the packages ledft over). 2) build the provides list
based 100% on the remote packages.

I will start playing with it and start posting some devels...

keep brainstorming if you think of more! thanks!

Greg

On Thu, Oct 10, 2002 at 10:21:26AM -0400, Jef Spaleta wrote:
> On Wed, 2002-10-09 at 19:02, Ami Fischman wrote:
> > Or am I missing something?
> 
> 
> I think the risky thing is what happens if the provides/requirments
> lists make an unexpected change..like requirement X is no longer needed
> in a later version or appears in the version in the new major release
> you want to upgrade to. 
> And how many loops does grab go through to find the full web of
> dependancies before it gives up?
> 
> Algorithm:
> 0) pass grab a list selected packages to upgrade...the normal grab
> method of selecting package status (U,u,O,o,N,n) is still valid for this
> first step....
> 1) take the first package in that selected package list and test for dep
>    issues
> 2) test for missing dependancies/unfillable dependances 
>    keep up with missing requirements/provides and affected already
>    installed packages via something just a bit more clever than 
>    rpm -q --whatprovides `rpm -q --requires selected-package`
> 
> 3)search the repositories for updates that fix the 
>   provides/requirements or update the affected packages that use to
>   provide/require something that is missing.  
> 
>   note: what happens if you find multiple updatable packages? in all
> your grab servers? Which version do you actually include in the update
> list...here is where some sort of tiered server list would prove very
> useful.  Because ideally you want to pull support packages from the same
> server that your original requested a package (step 1) in the event
> there are multiple "newer" versions of the package available in your big
> list of grabable servers. Atleast keeping up which which server the
> original package came from and first look for supporting packages
> there...regardless of whether they are the "newest" versions of a
> package. Then follow a tiered server list, so you don't end of in a
> weird cyclic problem where you need a support pack for a dependance that
> doesn't really exist anymore in the target repository if you had
> selected the rpm from the correct source. Having some idea as to which
> server to prefer packages from is key...becuase you can't just go by
> version number of the package..
> 
> 4) compile a list of all the packages you found in 3 and test them as in
> step (2) as a group...repeat this until you either hit an unresolvable
> dep(or your dep finding algorithm asks you to install two versions of
> the same package..which could happen and is an idication you pulled
> something from outside the target repository to fill a weirdo dep
> issue)...or your list of support rpm's for that single request update is
> complete and shows and not causing any problems. You might want to build
> in some controlled max number of loops to do here. IF you are trying to
> resolve nested dependances that are say 10 or more layers nested, you
> should probably think about it a bit before ask grab to attempt it, then
> set the maxdepth higher and let grab do it for you.  
> 
> 5) start at step (1) again with the next selected package for upgrade
> tacked on to the already verified chain of packages (again if the next
> selected package is a different version than something you have verified
> as a reasonable support package from a previous loop...error out or drop
> the selected package as a duplicate...dont try to install two packages
> of the same name.)
> 
> 6) once all the selected packages have either been discarded or gone
> through the support package verification steps...you can download all
> 132 packages you need to upgrade.
> 
> -jef



-- 
Greg Kurtzer
[email protected]
http://www.runlevelzero.net
LINUX,... The choice of a GNU generation!
:wq