From owner-freebsd-ports@FreeBSD.ORG Mon Jun 11 06:36:25 2012 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA10F106564A; Mon, 11 Jun 2012 06:36:25 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 198088FC12; Mon, 11 Jun 2012 06:36:24 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q5B6aLJx033290 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 11 Jun 2012 07:36:21 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: OpenDKIM Filter v2.5.2 smtp.infracaninophile.co.uk q5B6aLJx033290 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1339396581; bh=Qcf7PYVCm6N4Geh6bKXCgmflyTys6hhJ5+kLtnDe2Ew=; h=Date:From:To:CC:Subject:References:In-Reply-To:Content-Type: Message-ID:Mime-Version; b=ckPdd8dajv1xVPX5QlupbHoMEnqdJUYB35eOrgXV+22MAR1aysdKAzoHMQP2/2vPP uxCQn9iuJhTKg6PIw5gFDjo99xO03FQsU8SfvQD3ciqXsFWmDu31+W++BAHCZf/FES RwHdJJpHc+dXuScq2iSacV6z/KwY4mntbFSxR5gQ= Message-ID: <4FD591DF.3060808@infracaninophile.co.uk> Date: Mon, 11 Jun 2012 07:36:15 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Baptiste Daroussin References: <20120611043001.GO60433@ithaqua.etoilebsd.net> In-Reply-To: <20120611043001.GO60433@ithaqua.etoilebsd.net> X-Enigmail-Version: 1.4.2 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDF15EC2F119C4E73A739BA2A" X-Virus-Scanned: clamav-milter 0.97.4 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DKIM_ADSP_ALL,DKIM_SIGNED,T_DKIM_INVALID autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: ports@freebsd.org Subject: Re: ports need a uniq identifier, do you have any suggestion? X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 06:36:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDF15EC2F119C4E73A739BA2A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/06/2012 05:30, Baptiste Daroussin wrote: > In the ports tree we lack a unique identifier, while we could live with= out it > until now, it is more than needed for 2 upcoming features: pkgng and st= age > directory support. >=20 > unique means something that will always be the same what ever the optio= ns are > and what ever the runtime they use are. But also means unique in term o= f in the > whole ports no other package will share its identifier. >=20 > currently the only equivalent of this in the ports tree is the origin o= f a > package, which will no more be unique with the upcoming sub package sup= port > (coming along with stage directory) aka 1 origin to produce n package. >=20 > UNIQUENAME and LATEST_LINK fails in that area because they both can cha= nge > according to the runtime: py27- for example which will become py30- if = you > change the default python. > LATEST_LINK by default also append the PKGNAMEPREFIX which some ports c= an be > really creative with. >=20 > should we introduce something new, should we fix one of the above? do y= ou have > any suggestion? I was looking at this. You'ld think from the name that UNIQUENAME is the appropriate variable here. Yet by my calculations there are 1439 ports using non-unique UNIQUENAME variables. Fixing that seems like common sense to me: why call it unique if it isn't? UNIQUENAME importance being because the default location for a port's OPTIONSFILE is derived from it, and non-uniqueness can lead to ports fighting over control of that file? Which is bad when unintentional, but can be useful for some related ports to share the same options settin= gs. Does pkgng really need LATEST_LINK at all? As far as I recall, that only exists so that the user can say: # pkg_add -r firefox without having to look up the version number of the firefox port. But pkg(1) pretty much already lets you do that, maybe with the aid of '-x' or '-X' options. Come the pkgng revolution, LATEST_LINK should be one of the first against the wall. I don't see the problem with port prefixes changing UNIQUENAME. Isn't py27-foo conceptually a different port to py30-foo ? Yes, they are built from the same port ORIGIN, but you already intend dropping the one-to-one correspondence between port ORIGINS and packages with the introduction of sub-ports. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enigDF15EC2F119C4E73A739BA2A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/VkeUACgkQ8Mjk52CukIwILgCfVH4X/I10IMvmTmNQVXjW18cP 2lgAoIqsqEf4oEJ0ZtMNA6qHDYkj3r9M =Xf6T -----END PGP SIGNATURE----- --------------enigDF15EC2F119C4E73A739BA2A--