[CFT] UNIQUENAME patches
Matthew Seaman
matthew at FreeBSD.org
Fri Jun 15 07:44:16 UTC 2012
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20120615/0f7227fb/signature.pgp
More information about the freebsd-ports
mailing list