Date: Wed, 13 Jun 2012 16:21:16 +0100 From: Matthew Seaman <matthew@FreeBSD.org> To: freebsd-ports <freebsd-ports@FreeBSD.org> Subject: [CFT] UNIQUENAME patches Message-ID: <4FD8AFEC.6070605@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig896C76CD362983F349EF3C1A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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=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 welcome.= Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enig896C76CD362983F349EF3C1A 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/Yr+0ACgkQ8Mjk52CukIwORQCePinWqvYhthHN7vZzEKhX0Tw/ KioAni4mnkYON/slr8DLFZZYpC2T6DFj =/U6g -----END PGP SIGNATURE----- --------------enig896C76CD362983F349EF3C1A--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FD8AFEC.6070605>