[kris@freebsd.org: cvs commit: ports/Mk bsd.port.mk]

[Kris Kennaway]

On Mon, Apr 21, 2003 at 02:51:56AM +0300, Maxim Sobolev wrote:

> > I gave it a try, but the recursive-upgrade target is not so easy.  I
> > wrote a modified ALL-DEPENDS-LIST that recurses into children and
> > sorts their dependencies in topological order, but it is very slow
> > (~10 minutes for gnome2).
> 
> Maybe I am missing something, but what's wrong with make package-depends
> target? It does this in a reasonable time even for packages with very long
> dependency lists.

You implicitly answered that in your next sentence.

> I think that it should be fairly easy to make it
> printing not only raw list, but to sort it in a dependency order

This is the part that makes it take longer.  ALL-DEPENDS-LIST doesn't
recurse into children it has already seen, because we only care about
the list of dependencies and not the relationship between them.  But
in order to get the topological order (required for upgrading packages
in the right order), you need to recurse into the child for every
package that references it, otherwise you miss linkages in the graph
and you don't get the right sorting order.

e.g.

 A
/|\
|B C
||  \
||   D
\E--/
 | 
 F 

ALL-DEPENDS would visit in the order

A__
|\ \
E B C
|   |
F   D

This of course misses the essential structure of the graph.
TOP-DEPENDS cannot do this because it needs to traverse every link on
the graph.  So it could do

A__
|\ \ 
E B C
| | |
F E D
  | |
  F E
    |
    F

Of course, this traverses some links multiple times, but it's more
difficult to optimize it in a recursion-based approach (how
ALL-DEPENDS currently works) because one branch of the recursion needs
to know if another branch has already seen this node, and this
non-local information is simply not present.  This extra recursion is
what kills complex packages like gnome.

> by
> propagating some number into the recursion process, which will be
> printed along with the name of dependency and will be increased on each
> recursion level. Then you will be able to tell that packages with
> the same numbers doesn't depend on each other, wile those with greater
> numbers are dependencies for those with smaller ones - see the graph
> below:

I'm not sure this is going to help avoid the extra recursion, but
maybe I just haven't thought about it enough.  You're very welcome to
try.

> > Instead the way to do this would be to
> > parse the dependencies listed in INDEX, which is what portupgrade does
> > (like portupgrade, this would assume you have an up-to-date INDEX).
> 
> I think you are mistaken here. portupgrade uses INDEX only in the
> case when it has trouble finding root of the installed package using
> ORIGIN feature. Past experience suggests that INDEX is very poor source
> of dependency information due to its stale-most-of-the-time nature.

OK, I've not read the source code, so I may be missing something.

> Hm, execuse me my sarcasm, but do we really need the second portupgrade
> in C???

Well, what are the other possibilities for a base system tool?  I can
easily imagine that a shell script implementation would quickly become
a nightmare, because sh is a very poor language for structured or
modular programming.

Kris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20030420/4675f743/attachment.bin