Proposal for another category in INDEX: common_deps

[Matthew Seaman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Doug Barton wrote:
> Matthew Seaman wrote:
> 
>> 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.
> 
> Everything that is needed to build the port must be in BUILD_DEPENDS.
> Everything necessary to run the port must be in RUN_DEPENDS. This is
> needed to support building packages on one machine, and running them
> on another.

In terms of what you need in port Makefiles, then yes.  In terms of
what goes into the INDEX, then no. I was intending only to change
the format and content of the INDEX.  Calling the INDEX columns by
the same names as the Make variables they are (mostly) derived from
has now got the the state where it is more confusing than
enlightening, so thinking up different column names sounds like a
good idea to me.

In terms of Makefile variables, BUILD_DEPENDS has a quite specific
meaning: it all the extra software that must be present at the time
the 'do-build:' target in the port Makefile is reached.  Of the
others, (which apply analogously to the 'do-fetch:', 'do-extract:',
'do-patch:' targets.) EXTRACT_DEPENDS is used reasonably frequently,
generally for ports that need unzip to extract them.  Otherwise
those variables tend to be empty because the base system supplies
all of the necessary functionality. libarchive nowadays can
unpack zips so many more of the EXTRACT_DEPENDS variables will
eventually end up empty as well.

Do I think the whole architecture of the ports system should be
changed to eliminate most of the *_DEPENDS targets?  No.  Too much
pain for no gain.

Do I think it's worth having a separate column in the INDEX for the
contents of those variables?  No.

>> -- 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.
> 
> I don't see how we need a separate LIB_DEPENDS to achieve this. Can
> you describe in more detail the mechanism you have in mind?

The idea was that anything in a LIB_DEPENDS target of a port would a
a shared library to be linked against, and it's only the software
that links against the shlib that needs to be recompiled if the
shlib ABI changes.  However I see on reflection that this doesn't go
far enough: DSO modules have the same sort of linkage requirement,
but don't get mentioned in LIB_DEPENDS

Again, the idea here was not to change anything in the ports
themselves: just what was presented in the INDEX, and then mainly as
a resource to make easier the lives of the people that write ports
management software.

	Cheers,

	Matthew

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

iD8DBQFGocLJ8Mjk52CukIwRCBeTAJ9YCTbgTWo9N71pssC5ZgqJO1GD/wCfUs4g
NitUYwteyQDZnZ1392pAbjQ=
=akvP
-----END PGP SIGNATURE-----