Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 15 Jun 2012 08:43:59 +0100
From:      Matthew Seaman <matthew@FreeBSD.org>
To:        Jason Helfman <jgh@FreeBSD.org>
Cc:        Baptiste Daroussin <bapt@FreeBSD.org>, freebsd-ports <freebsd-ports@FreeBSD.org>
Subject:   Re: [CFT] UNIQUENAME patches
Message-ID:  <4FDAE7BF.6020606@FreeBSD.org>
In-Reply-To: <20120614230617.GT26321@dormouse.experts-exchange.com>
References:  <4FD8AFEC.6070605@FreeBSD.org> <20120614080633.GV60433@ithaqua.etoilebsd.net> <20120614230617.GT26321@dormouse.experts-exchange.com>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig964C109A18D8B3C5D34B6390
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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, plu=
s
>>> 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/or=
ca
>>>      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 f=
or
>>>      that LANG.  Otherwise it is only set for the specific ports wher=
e
>>>      there is a directory name collision, usually based on the catego=
ry
>>>      names.
>>>
>>>    * To avoid accidental non-uniqueness, UNIQUENAME should be treated=

>>>      as a read-only variable by port maintainers.  UNIQUEPREFIX shoul=
d
>>>      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 turne=
d
>>>      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=3D ${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 welc=
ome.
>>>
>>> 	Cheers,
>>>
>>> 	Matthew
>>>
>>> --
>>> Dr Matthew J Seaman MA, D.Phil.
>>> PGP: http://www.infracaninophile.co.uk/pgpkey
>>>
>>>
>>>
>=20
>> 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.
>=20
>> It also solve another problem which is really important when dealing w=
ith 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 work=
arounding
>> 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 is=
n't an
>> ideal solution to track them in full binary world)
>=20
>> The other thing that it could solve for binary only world if that if p=
eople 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 py=
thon27 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.
>=20
>> Last but no least once it is done the LATEST_LINK overwrite could die,=
 and the
>> feature associated could just use LATEST_LINK.
>=20
>> Please do test this patch comment on it and improve it.
>=20
>> regards,
>> Bapt
>=20
> Great patch. I've done some testing, but was aware of this issue, and e=
ven
> have raised this with bapt during his implementation of optionsng to se=
e if
> he knew of this issue.
>=20
>  From what I can see, this also takes care of this PR, but also adds so=
me
> needed consistency that has long been removed.
>=20
> And by looking up the pr, I see you already have found it :)
>=20
> http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/148637
>=20
> I humbly suggest to move this PR to an open state.
>=20
> Great work, Matthew!
>=20
> 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

--=20
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey





--------------enig964C109A18D8B3C5D34B6390
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/a58UACgkQ8Mjk52CukIy4wQCbBe3zHzNjlXF7615sntwwh/Qd
6kIAnAk6FxRyt9Q9IxasmyY4tfey6YKZ
=+KDW
-----END PGP SIGNATURE-----

--------------enig964C109A18D8B3C5D34B6390--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FDAE7BF.6020606>