Proposal for another category in INDEX: common_deps

[Michel Talon]

Doug Barton wrote:

> > and then mainly as a resource to make easier the lives of the
> > people that write ports management software.
> 
> Well, I'm one of those people, and portmaster ignores the index file
> altogether, for whatever that's worth.

Me too for pkgupgrade. In my case the rationale is that, if something
has to be compiled on the machine, it is best that the information is
exactly compatible with the state of the ports tree on the machine.  So
like portmaster, pkgupgrade recomputes the Index fields for all
installed ports and their dependencies. This is no big deal, uses less
than a minute on a modern machine, totally negligible compared to the
time for downloading distfiles or packages, or running pkg_delete or
pkg_add. In pkgupgrade case one needs to deal with both binary packages
and ports, so RUN_DEPENDS is used to discover dependencies of packages,
and all other fields coalesced to discover dependencies of ports. There
is of course a further subtelty: you have to compare old and new ports
which may have changed name in between. The rule i have taken is to
systematically  use the most recent name as it appears in the ports
tree, and evolve old names following the MOVED file (perhaps
recursively) to be able to compare them with new names. This leaves on
the border of the road ports which have disappeared in between, but
anyways you cannot upgrade them by source ... I think that portmaster
does more or less the same, while, if i don't err, portupgrade doesn't
and tries to guess new names using heuristics, which sometimes
spectacularly fails.

Well, all this to say that, for the purpose of upgrading a port, it is
the coalesced values of fetch, extract, etc. which is of interest. Of
course, for other purposes, like Mark Linimon says, these fields may
have individual interest.



-- 

Michel TALON