[CFT] UNIQUENAME patches

[Jason Helfman]

-----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-----