bsd.port.mk LATEST_LINK / UNIQUENAME questions & patch
Oliver Eikemeier
eikemeier at fillmore-labs.com
Thu Feb 12 18:18:38 PST 2004
Brandon D. Valentine wrote:
> I'm updating some ports to fix duplicate LATEST_LINKs and have observed
> the following. I would appreciate feedback on it.
>
> UNIQUENAME (line 1039) is defined before LATEST_LINK (line 2618) in
> bsd.port.mk but the definition of UNIQUE_NAME is wrapped in a
> conditional test for the existence of LATEST_LINK.
>
> If a port sets LATEST_LINK in it's Makefile before including bsd.port.mk
> then UNIQUENAME gets set to LATEST_LINK. If a port does not set
> LATEST_LINK, then UNIQUENAME gets set to ${PKGNAMEPREFIX}${PORTNAME} and
> LATEST_LINK gets set to ${PKGBASE}, which expands to
> ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}.
>
> In the case where a port does not set LATEST_LINK, LATEST_LINK and
> UNIQUENAME can have different values. It seems to me that UNIQUENAME
> should include PKGNAMESUFFIX as well or by default be equivalent to
> LATEST_LINK. The current behavior could cause master / slave ports that
> set PKGNAMESUFFIX to have the same UNIQUENAME. Is this desirable? Do
> we assume master / slave ports always conflict? If they don't already
> exist I can forsee master / slave ports which need to coexist.
To sum up some of the design decisions:
- we needed an unique name for port OPTIONS, LATEST_LINK was designed to be
that in most cases (i.e. apache vs. apache2)
- The name of LATEST_LINK seemed too confusing, so UNIQUENAME was invented.
- If a port defineds LATEST_LINK it is normally the right thing, so UNIQUENAME
defaults to that.
- defaulting UNIQUENAME to include PKGNAMESUFFIX doesn't seem like the right
thing to do, since some ports define PKGNAMESUFFIX *after* seeing their
options (-nox11 for example)
the consquence is that all -client and -server ports and every port that wants
to include the PKGNAMESUFFIX in the OPTIONSFILE name have to set either LATEST_LINK,
UNIQUENAME or both.
I agree that this is totally heuristic, but we hope that it is the *right* heuristic.
> The attached patch defines PKGBASE and LATEST_LINK near the top of the
> Makefile, just above the definition of UNIQUENAME and does away with the
> conditional around UNIQUENAME's definition. This patch is untested as
> the only box currently at my disposal for testing at this moment is in
> the middle of a massive portupgrade.
Appreciated, but check first how many port benefit and how many ports you'll harm
with this patch. See above rationale.
> I have also noticed that DOCSDIR, EXAMPLESDIR, and DATADIR are set to
> ${PREFIX}/share/doc/${PORTNAME} right now. My patch changes them to
> ${PREFIX}/share/doc/${UNIQUENAME} so that the documentation will not
> collide in ports where different versions of a product may share the
> same PORTNAME. I didn't see any other obvious places where PORTNAME
> should become UNIQUENAME.
The same as above: name some ports that will benefit. After this patch
you'll have to fix some ports, e.g. security/clamav-devel, so it isn't that easy.
More information about the freebsd-ports
mailing list