From owner-freebsd-ports@FreeBSD.ORG Fri Jun 15 07:44:16 2012 Return-Path: Delivered-To: freebsd-ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B36B106564A; Fri, 15 Jun 2012 07:44:16 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (lucid-nonsense.infracaninophile.co.uk [81.187.76.162]) by mx1.freebsd.org (Postfix) with ESMTP id D43C78FC0A; Fri, 15 Jun 2012 07:44:15 +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 q5F7i5JF005766 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 15 Jun 2012 08:44:05 +0100 (BST) (envelope-from matthew@FreeBSD.org) X-DKIM: OpenDKIM Filter v2.5.2 smtp.infracaninophile.co.uk q5F7i5JF005766 Authentication-Results: smtp.infracaninophile.co.uk/q5F7i5JF005766; dkim=none (no signature); dkim-adsp=none Message-ID: <4FDAE7BF.6020606@FreeBSD.org> Date: Fri, 15 Jun 2012 08:43:59 +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: Jason Helfman References: <4FD8AFEC.6070605@FreeBSD.org> <20120614080633.GV60433@ithaqua.etoilebsd.net> <20120614230617.GT26321@dormouse.experts-exchange.com> In-Reply-To: <20120614230617.GT26321@dormouse.experts-exchange.com> X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig964C109A18D8B3C5D34B6390" X-Virus-Scanned: clamav-milter 0.97.4 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: Baptiste Daroussin , freebsd-ports Subject: Re: [CFT] UNIQUENAME patches 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: Fri, 15 Jun 2012 07:44:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig964C109A18D8B3C5D34B6390 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 15/06/2012 00:06, Jason Helfman wrote: > On Thu, Jun 14, 2012 at 10:14:52AM +0200, Baptiste Daroussin thus spake= : >> On Wed, Jun 13, 2012 at 04:21:16PM +0100, Matthew Seaman wrote: >>> >>> Dear all, >>> >>> After recent mention in this list that UNIQUENAME is not actually a >>> unique name for each port and how obviously non-sensical that is, plu= s >>> how it causes various problems with OPTIONS processing and how having= a >>> proper UNIQUENAME will facilitate the new sub-package functionality >>> currently on the drawing board. >>> >>> So, here are some patches: >>> >>> http://people.freebsd.org/~matthew/uniquename/uniquenames.diff >>> >>> There's also some data on the effect these have on OPTIONSFILE and >>> UNIQUENAME values per port in >>> >>> http://people.freebsd.org/~matthew/uniquename/before/* >>> http://people.freebsd.org/~matthew/uniquename/after/* >>> >>> Summarizing the changes: >>> >>> * UNIQUENAME is now unique per port, and is primarily derived from= >>> the port directory name. >>> >>> * Where the port directory name isn't unique (eg. accessibility/or= ca >>> vs graphics/orca) there is a new UNIQUEPREFIX variable to >>> distinguish the affected ports. This is set for all the LANG >>> specific category ports (arabic, chinese, french, german, hebrew= , >>> hungarian, japanese, korean, polish, portuguese, russian, >>> ukranian, vietnamese) to the standard 2 character abbreviation f= or >>> that LANG. Otherwise it is only set for the specific ports wher= e >>> there is a directory name collision, usually based on the catego= ry >>> names. >>> >>> * To avoid accidental non-uniqueness, UNIQUENAME should be treated= >>> as a read-only variable by port maintainers. UNIQUEPREFIX shoul= d >>> only be set where necessary to resolve conflicts. All instances= of >>> ports setting UNIQUENAME have been removed: in the majority of >>> cases, this turned out to be a no-op as the new UNIQUENAME turne= d >>> out to be the same as what most ports were previously overriding= >>> it to. >>> >>> * The way UNIQUENAME is defined means that it doesn't now change >>> depending on the version of python, ruby or apache installed on = a >>> machine. >>> >>> * UNIQUENAME will have changed for numerous ports -- consequently >>> port OPTIONFILEs may well have changed location. By default now= , >>> each port should have an individual OPTIONFILE location. This >>> has removed a number of accidental cases of different (maybe >>> completely unrelated) ports sharing the same OPTIONSFILE. >>> >>> * If you do want to share the same OPTIONSFILE between several >>> different ports, you can modify OPTIONSFILE directly or there is= >>> now a new OPTIONS_DIR variable allowing a simple way for you to >>> override the location: OPTIONSFILE is redefined as: >>> >>> OPTIONSFILE=3D ${PORT_DBDIR}/${OPTIONS_DIR}/options >>> >>> with OPTIONS_DIR defaulting (as before) to UNIQUENAME unless >>> overriden. See databases/postgresql91-server for an example. >>> >>> * Other things that may be affected: ports with USE_LDCONFIG or >>> USE_LDCONFIG32 can have ldconfig data written to a different >>> location. This shouldn't make any user-visible change. >>> Per-port options settings (OPTIONSng-style) in /etc/make.conf >>> may need to be modified. >>> >>> Please test. Comments, corrections and bug reports will be most welc= ome. >>> >>> Cheers, >>> >>> Matthew >>> >>> -- >>> Dr Matthew J Seaman MA, D.Phil. >>> PGP: http://www.infracaninophile.co.uk/pgpkey >>> >>> >>> >=20 >> Thank you very much for the patch, it solves a problem that sticks for= way too >> long in the ports tree: the problem with options files. >=20 >> It also solve another problem which is really important when dealing w= ith binary >> packages and will allow to simplify the life of pkgng development: we = would for >> real get a unique identifier for a package!!!, before for we were work= arounding >> the problem considering origin as our unique identifier which "worked"= but no >> that good, it was hard to track a package which was moved (no MOVED is= n't an >> ideal solution to track them in full binary world) >=20 >> The other thing that it could solve for binary only world if that if p= eople from >> python ruby perl and others uses always the same uniquename for their = default >> version, then it will be easy to move from python26 as a default to py= thon27 as >> a default in full binary environment with no manual intervention from = the user >> and no complex hacks to figure it out in the package tool. >=20 >> Last but no least once it is done the LATEST_LINK overwrite could die,= and the >> feature associated could just use LATEST_LINK. >=20 >> Please do test this patch comment on it and improve it. >=20 >> regards, >> Bapt >=20 > Great patch. I've done some testing, but was aware of this issue, and e= ven > have raised this with bapt during his implementation of optionsng to se= e if > he knew of this issue. >=20 > From what I can see, this also takes care of this PR, but also adds so= me > needed consistency that has long been removed. >=20 > And by looking up the pr, I see you already have found it :) >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/148637 >=20 > I humbly suggest to move this PR to an open state. >=20 > Great work, Matthew! >=20 > Thanks! > -jgh If people want to get a feeling for the changes involved in this patch, I've put together a script to scan the ports tree and highlight UNIQUENAME (and port name) conflicts. http://people.freebsd.org/~matthew/uniquename/uniquecheck No output is good, unless you turn up the verbosity. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enig964C109A18D8B3C5D34B6390 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/a58UACgkQ8Mjk52CukIy4wQCbBe3zHzNjlXF7615sntwwh/Qd 6kIAnAk6FxRyt9Q9IxasmyY4tfey6YKZ =+KDW -----END PGP SIGNATURE----- --------------enig964C109A18D8B3C5D34B6390--