Proposal for another category in INDEX: common_deps

[Matthew Seaman]

-----BEGIN PGP SIGNED MESSAGE-----
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
EXTRACT_DEPENDS, FETCH_DEPENDS, PATCH_DEPENDS, BUILD_DEPENDS[*]
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.

	Cheers,

	Matthew

[*] 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: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGoHEf8Mjk52CukIwRCGXYAJ9aFO3BAWJU+HKWhx3fMJ4ZjnI5lgCeJ/Bl
hULiTPawL83GYKEP5hgm0Zk=
=DNH/
-----END PGP SIGNATURE-----