Proposal for another category in INDEX: common_deps

Michel Talon talon at
Fri Jul 20 15:11:31 UTC 2007

Matthew Seaman wrote:

> Another interesting idea would be to separate out the LIB_DEPENDS
> data.  At the moment there is a separate LIB_DEPENDS variable that
> can be used in Makefiles, but the INDEX processing includes the
> LIB_DEPENDS data with both the BUILD_DEPENDS and the RUN_DEPENDS
> fields.  Keeping LIB_DEPENDS separate should allow a useful
> optimization in the case of shlib ABI version number bumps.

Clear that you are the author of
and so know the state of the Index stuff from inside out!

Personnally i think there are far too many totally useless categories
here, as you are saying, only RUN_DEPENDS and BUILD_DEPENDS have any
usefulness, the first if you install from packages, the second if you
install from ports. It is totally irrelevant to know if a dependency is
FETCH, EXTRACT or whatever, since you need it anyway to build the
port. Merging LIB_DEPENDS in both BUILD and RUN is justified since you
need the libraries both for compiling and for running the port.

Introducing a lot of dependency categories renders writing an upgrade
mechanism very complicated. Either you coalesce everything into one big
category, voiding the distinctions of their content, or you have to
introduce an infinitely complicated logic to take care of them. For
example you explain that knowing only LIB_DEPENDS would help knowing
what to upgrade when gettext is bumped. But other ports may have
important dependencies not going through LIB_DEPENDS. You need a crystal
ball to disentangle all the cases. An upgrade mechanism can proceed with
a mixture of packages and ports, for example portupgrade -P. The only
relevant info for determining what to install or build previously is
RUN_DEPENDS and BUILD_DEPENDS. Everything else is garbage. The Debian
people have a simpler situation with apt-get, they have only one sort of
dependency to consider, the equivalent of RUN_DEPENDS. Hence they can
build a reliable sorted graph of dependencies.


Michel TALON

More information about the freebsd-ports mailing list