From owner-freebsd-ports@FreeBSD.ORG Fri Jun 15 09:01:00 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 48EB91065782; Fri, 15 Jun 2012 09:01:00 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 29C828FC16; Fri, 15 Jun 2012 09:01:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5F910MH005368; Fri, 15 Jun 2012 09:01:00 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5F90xBo005339; Fri, 15 Jun 2012 09:00:59 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Fri, 15 Jun 2012 11:00:55 +0200 From: Baptiste Daroussin To: Matthew Seaman Message-ID: <20120615090055.GE98264@ithaqua.etoilebsd.net> References: <4FD8AFEC.6070605@FreeBSD.org> <20120614080633.GV60433@ithaqua.etoilebsd.net> <20120614230617.GT26321@dormouse.experts-exchange.com> <4FDAE7BF.6020606@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tMbDGjvJuJijemkf" Content-Disposition: inline In-Reply-To: <4FDAE7BF.6020606@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Jason Helfman , 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 09:01:00 -0000 --tMbDGjvJuJijemkf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 15, 2012 at 08:43:59AM +0100, Matthew Seaman wrote: > 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, plus > >>> 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 where > >>> 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 should > >>> 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 turned > >>> 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 >=20 > 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. >=20 > http://people.freebsd.org/~matthew/uniquename/uniquecheck >=20 > No output is good, unless you turn up the verbosity. >=20 > Cheers, >=20 > Matthew >=20 > --=20 > Dr Matthew J Seaman MA, D.Phil. > PGP: http://www.infracaninophile.co.uk/pgpkey >=20 >=20 >=20 >=20 Get this script in Tools/scripts maybe after your patch gets in that can be useful! regards, Bapt --tMbDGjvJuJijemkf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/a+ccACgkQ8kTtMUmk6EyJ9gCeIVknAhiSKH048DX4sl3kC93r fzcAn0RcGUqu+VSOOJPM+kR61j6LKAwE =e8z9 -----END PGP SIGNATURE----- --tMbDGjvJuJijemkf--