From owner-freebsd-ports@FreeBSD.ORG Thu Jun 14 23:07:56 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 93AF41065673 for ; Thu, 14 Jun 2012 23:07:56 +0000 (UTC) (envelope-from bsd-src@helfman.org) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5A6948FC0C for ; Thu, 14 Jun 2012 23:07:56 +0000 (UTC) Received: by dadv36 with SMTP id v36so3377616dad.13 for ; Thu, 14 Jun 2012 16:07:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:x-operating-system:organization :x-living-the-dream:x-pgp-fingerprint:x-pgp-key:user-agent :x-gm-message-state; bh=utZAgERFPDoF0xp52ycohKQSGztbbN7+fNiMqlBaftM=; b=SHYDfRZq60QQ0NApsOogvfjNQIrN2SpmlRg8O4zOmvDH6vbW+jTjSUYcx9UvoE/Ypl JkZR2eXKzZ7BBMvTYrIs9SlysmpJPKcLtHv9C6qsmdIKgGLAkjEHcM1DZs2P3V0qAK+Y Hjcdyp9r3QR7Q5yRgfCcvF7nV3Bi69qsmi4cs7eNxoewKwT7TEvZPIxrBfEWS/M4Ba3f 3LBrUOW1o8hFZ9Mv6WoCYCaYq5UYfnj0sFx0RI+WaRrdVem0/tVFftD0yHTIpzrFD9EE cqKHuRcvX6WomTTkSCH3HSY7w93zRZpadW7OQ71dQqHX/O/sMT4evBTJ4WZMkcVeWapW PXAA== Received: by 10.68.217.229 with SMTP id pb5mr12754631pbc.20.1339715272906; Thu, 14 Jun 2012 16:07:52 -0700 (PDT) Received: from dormouse.experts-exchange.com ([72.29.164.238]) by mx.google.com with ESMTPS id ku7sm10999300pbc.31.2012.06.14.16.07.51 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Jun 2012 16:07:51 -0700 (PDT) Sender: Jason Helfman Date: Thu, 14 Jun 2012 16:06:17 -0700 From: Jason Helfman To: Baptiste Daroussin Message-ID: <20120614230617.GT26321@dormouse.experts-exchange.com> References: <4FD8AFEC.6070605@FreeBSD.org> <20120614080633.GV60433@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed In-Reply-To: <20120614080633.GV60433@ithaqua.etoilebsd.net> X-Operating-System: FreeBSD 8.3-RELEASE amd64 Organization: The FreeBSD Project, http://www.freebsd.org X-Living-The-Dream: I love the SLO Life! X-PGP-FingerPrint: 8E0D C457 9A0F C91C 23F3 0454 2059 9A63 4150 D3DC X-PGP-Key: http://people.freebsd.org/~jgh/jgh.asc User-Agent: Mutt/1.5.21 (2010-09-15) X-Gm-Message-State: ALoCoQkSxG0IiEw5sCksXNWyfnxTYYTsssArBKsRrSF1YDMt7UL+FOo3FmZnDCi1aRf89tN2pK21 Cc: Matthew Seaman , 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: Thu, 14 Jun 2012 23:07:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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/orca >> 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 for >> that LANG. Otherwise it is only set for the specific ports where >> there is a directory name collision, usually based on the category >> 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= ${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 welcome. >> >> Cheers, >> >> Matthew >> >> -- >> Dr Matthew J Seaman MA, D.Phil. >> PGP: http://www.infracaninophile.co.uk/pgpkey >> >> >> > >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. > >It also solve another problem which is really important when dealing with 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 workarounding >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 isn't an >ideal solution to track them in full binary world) > >The other thing that it could solve for binary only world if that if people 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 python27 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. > >Last but no least once it is done the LATEST_LINK overwrite could die, and the >feature associated could just use LATEST_LINK. > >Please do test this patch comment on it and improve it. > >regards, >Bapt Great patch. I've done some testing, but was aware of this issue, and even have raised this with bapt during his implementation of optionsng to see if he knew of this issue. From what I can see, this also takes care of this PR, but also adds some needed consistency that has long been removed. And by looking up the pr, I see you already have found it :) http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/148637 I humbly suggest to move this PR to an open state. Great work, Matthew! Thanks! - -jgh - -- Jason Helfman FreeBSD Committer | http://people.freebsd.org/~jgh | The Power To Serve -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJP2m5pAAoJECBZmmNBUNPcmoEIAJdkYJ+BnpttWtENMZffrCbc VRHQWV47DmqNGW38KxuWzs1M0yoyD319vJ+5Znr14+IcrIww4iDoDNpsvjAw1NWC xS4BrXL3g0Uh8CL2QQzM3m1Rx9Zb7JBHERiJxBidVESrNSaRrLDlT9vbWd9Liz9r 2qh1g9z22PiMhtlDqU9WWzU3Nq1HW4OR2AFjv6SuW5Va6CRRvgJIPkL0vUoK+QKH Lhz4DaIzYq09ScN2kYLD+MSWuLRHzGSMtLzwVUwJSvyp5w5AMC9UoNwoaTt7RPZd GubpGf6wy1r9quPB77Cj6RFq9DqqZN9EetspwxS9y8xshX671uKPBRtwS3PcYI8= =7R9I -----END PGP SIGNATURE-----