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