From owner-freebsd-ports@FreeBSD.ORG Thu Feb 12 18:18:38 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A0BF16A4E1 for ; Thu, 12 Feb 2004 18:18:38 -0800 (PST) Received: from postman.arcor.de (postman4.arcor-online.net [151.189.0.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAECA43D1F for ; Thu, 12 Feb 2004 18:18:37 -0800 (PST) (envelope-from eikemeier@fillmore-labs.com) Received: from fillmore.dyndns.org (port-212-202-184-227.reverse.qdsl-home.de [212.202.184.227]) (authenticated bits=0)i1D2INUa007798 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 13 Feb 2004 03:18:23 +0100 (MET) Received: from [172.16.0.2] (helo=fillmore-labs.com) by fillmore.dyndns.org with esmtp (Exim 4.30; FreeBSD) id 1ArSuE-000ObQ-4j; Fri, 13 Feb 2004 03:18:14 +0100 Message-ID: <402C33E5.6070606@fillmore-labs.com> Date: Fri, 13 Feb 2004 03:18:13 +0100 From: Oliver Eikemeier Organization: Fillmore Labs GmbH - http://www.fillmore-labs.com/ MIME-Version: 1.0 To: "Brandon D. Valentine" References: <20040212082206.GF423@geekpunk.net> In-Reply-To: <20040212082206.GF423@geekpunk.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) User-Agent: KMail/1.5.9 cc: FreeBSD Ports Subject: Re: bsd.port.mk LATEST_LINK / UNIQUENAME questions & patch X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2004 02:18:38 -0000 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.