Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Jun 2012 10:14:52 +0200
From:      Baptiste Daroussin <bapt@FreeBSD.org>
To:        Matthew Seaman <matthew@FreeBSD.org>
Cc:        freebsd-ports <freebsd-ports@FreeBSD.org>
Subject:   Re: [CFT] UNIQUENAME patches
Message-ID:  <20120614080633.GV60433@ithaqua.etoilebsd.net>
In-Reply-To: <4FD8AFEC.6070605@FreeBSD.org>
References:  <4FD8AFEC.6070605@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--TX8FgYyhBart40Z+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 13, 2012 at 04:21:16PM +0100, Matthew Seaman wrote:
>=20
> Dear all,
>=20
> 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.
>=20
> So, here are some patches:
>=20
>    http://people.freebsd.org/~matthew/uniquename/uniquenames.diff
>=20
> There's also some data on the effect these have on OPTIONSFILE and
> UNIQUENAME values per port in
>=20
>    http://people.freebsd.org/~matthew/uniquename/before/*
>    http://people.freebsd.org/~matthew/uniquename/after/*
>=20
> Summarizing the changes:
>=20
>    * UNIQUENAME is now unique per port, and is primarily derived from
>      the port directory name.
>=20
>    * 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.
>=20
>    * 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.
>=20
>    * 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.
>=20
>    * 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.
>=20
>    * 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:
>=20
>        OPTIONSFILE=3D ${PORT_DBDIR}/${OPTIONS_DIR}/options
>=20
>      with OPTIONS_DIR defaulting (as before) to UNIQUENAME unless
>      overriden.  See databases/postgresql91-server for an example.
>=20
>    * 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.
>=20
> Please test.  Comments, corrections and bug reports will be most welcome.
>=20
> 	Cheers,
>=20
> 	Matthew
>=20
> --=20
> Dr Matthew J Seaman MA, D.Phil.
> PGP: http://www.infracaninophile.co.uk/pgpkey
>=20
>=20
>=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.

It also solve another problem which is really important when dealing with b=
inary
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 workaroun=
ding
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 defau=
lt
version, then it will be easy to move from python26 as a default to python2=
7 as
a default in full binary environment with no manual intervention from the u=
ser
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

--TX8FgYyhBart40Z+
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iEYEARECAAYFAk/ZnXwACgkQ8kTtMUmk6EzSDgCfSPnvbpsXYhrljNp0p63NBlq1
iUwAn3YTm+MDIxeMfc/Y6kb6woTCaXED
=MdFK
-----END PGP SIGNATURE-----

--TX8FgYyhBart40Z+--



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