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/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
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 -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey
signature.asc
Description: OpenPGP digital signature
