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

Maxim Sobolev sobomax at portaone.com
Sun Apr 20 16:51:58 PDT 2003

On Sun, Apr 20, 2003 at 02:58:32PM -0700, Kris Kennaway wrote:
> On Sun, Apr 20, 2003 at 07:02:09PM +0400, Sergey Matveychuk wrote:
> > Kris Kennaway wrote:
> > > The 'deinstall' improvement is particularly interesting.  It should
> > > not be a huge amount of work to make a decent 'make upgrade' and 'make
> > > recursive-upgrade' target that does a portupgrade-like sequence of
> > > backup/deinstall/build/install on the current port (and its
> > > dependencies).  I'd love it if someone felt like working on this!
> > 
> > I'v had this idea. And I'll plan to work for it within next week.
> > 
> > Has somebody comments or suggestion for it?
> 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. I think that it should be fairly easy to make it
printing not only raw list, but to sort it in a dependency order 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

P1            1
| \
P2 P3         2
|  |\
|  | \
P4 P5 P6      3
  /|\  \
 / | \  \
P7 P8 P9 P10  4
P11           5

By running such modified package-depends target in P1, you will get
after sorting:

P2 2
P3 2
P4 3
P5 3
P6 3
P7 4
P8 4
P9 4
P10 4
P11 5

Which will give you perfectly valid order of upgrade process (from
greater to smaller), and allso optionally can be used to do
parallel dependencies building, that would be useful on N-way
machines. You could ask, what if for example P11 also happens
to depend on say P4, but since information about already visited
dependencies only propagates downwards, you will visit P4 node
twice. Therefore, P4 will be printed two times, once on recursion
level 3 and once on recursion level 6, it should not be that hard
to select only one with highest recursion index (currently it
just gets filtered out by performing sort -u on received list
of dependencies).

> 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.

> I came to the conclusion that this wouldn't really fit inside
> bsd.port.mk, and it would be best to create a standalone pkg_upgrade
> tool that mirrors portupgrade.  Writing it in sh might be possible,
> but it would probably get very complicated.  As a first step I was
> thinking about writing some C code that wrote INDEX into a binary DB
> file, and which could read that into a tree structure in memory to
> discover the dependency graphs.  I don't know when I'll get time to
> work on this though.

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


More information about the freebsd-ports mailing list