Proposal for another category in INDEX: common_deps
Doug Barton
dougb at FreeBSD.org
Fri Jul 20 19:01:38 UTC 2007
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.
I do agree however that that the other categories should be coalesced
into BUILD_DEPENDS. I also agree that a lot of maintainers seem to
blindly copy dependencies into both categories without understanding why.
> 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
FWIW, the -r option for portmaster only rebuilds those ports that
depend directly on the new version, not things that depend on the
things that depend on it.
> -- 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?
Doug
--
This .signature sanitized for your protection
More information about the freebsd-ports
mailing list