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/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 > > > >
Get this script in Tools/scripts maybe after your patch gets in that can be useful! regards, Bapt
pgpyUscx92UZp.pgp
Description: PGP signature
