[CFT] UNIQUENAME patches

Fri Jun 15 09:01:00 UTC 2012

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20120615/477e0bd1/attachment.pgp