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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA9pYzmrWLDmRitRZURAqfTAKCWG3UO92GpM2dZzavELiqI4+iD9gCePAS/
ChcLNxVA1KZltrnwIahoHV0=
=P1V/
-----END PGP SIGNATURE-----