Proposal for another category in INDEX: common_deps

Matthew Seaman m.seaman at
Fri Jul 20 08:24:16 UTC 2007

Hash: SHA256

Garrett Cooper wrote:

>    I just ran a quick analysis with a Perl script and found that there
> are a number of similarities in the build_deps and run_deps fields in
> the INDEX files -- so many that I think that items common to both
> build_deps and run_deps should be isolated and put into a new category
> called 'common_deps':

Of all the *_DEPENDS fields in the INDEX, RUN_DEPENDS is the big
deal.  The other *_DEPENDS fields only apply at certain stages of
building and installing the package.  If you install from
pre-compiled pkgs many of those other dependencies would be
unnecessary to have installed.

In many ways it would be more useful to delete from the
lists in the INDEX any package that also appears in the RUN_DEPENDS
list.  This leaves the four listed fields with just the extra
packages that need to be present at build/install time.

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.

Take for example the effect of the devel/gettext port.  At the
moment, the usual advice when there's a shlib version bump for
gettext is to force a rebuild of everything that depends on it:

   portupgrade -fr gettext-0.16.1_3

This however means that anything that uses a tool that is linked
against gettext is forcibly recompiled -- and as gmake depends on
gettext that means a very large fraction of the ports most people
have installed.  However, if the only way an application depends on
gettext is via gmake /at build time/ then rebuilding that
application is really not necessary.  Using LIB_DEPENDS to
distinguish ports that are linked against any particular shlib
versus those that inherit a dependency against a shlib for other
reasons could save rather a lot of wasted CPU cycles.



[*] One thing that has puzzled me: why there is no 'INSTALL_DEPENDS'
variable?  Given there are variables to cover all of the other
principal stages in building a port, it seems an odd omission.

- --
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP:     Ramsgate
                                                  Kent, CT11 9PW
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla -


More information about the freebsd-ports mailing list