LATEST_LINK / UNIQUENAME questions & patch

Oliver Eikemeier eikemeier at
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
> 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
> then UNIQUENAME gets set to LATEST_LINK.  If a port does not set
> LATEST_LINK gets set to ${PKGBASE}, which expands to
> 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,

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