Date: Sat, 16 Jun 2012 16:39:07 +0200 From: Mel Flynn <rflynn@acsalaska.net> To: freebsd-ports@freebsd.org Subject: Re: [CFT] UNIQUENAME patches Message-ID: <4FDC9A8B.2040701@acsalaska.net> In-Reply-To: <CADLo83-Pr5Qqa6oUFKmfbLuuDOCiDQoiLVvjPfvJ1fT8ou0h9g@mail.gmail.com> References: <4FD8AFEC.6070605@FreeBSD.org> <CADLo83-Pr5Qqa6oUFKmfbLuuDOCiDQoiLVvjPfvJ1fT8ou0h9g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16-6-2012 15:18, Chris Rees wrote: > On 13 June 2012 16:21, Matthew Seaman <matthew@freebsd.org> 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. > > That's great-- though rather than patching colliding-only ports, can't > we just add the category to it? > > .for cat in ${CATEGORIES} > UNIQUEPREFIX?= ${cat} > .endfor I'm also for getting rid of the badly chosen default. Since origins are unique within the tree, we can simply use: UNIQUENAME=${PORTORIGIN:S,/,____,} Then once you get childports (tis the new and improved name for subpackages) you can tack that on there in the same way. On 16-6-2012 16:13, Matthew Seaman wrote: > 2) As a way of future-proofing against reorganizations of the ports > tree. What tends to happen is that a new category is invented > and a number of ports are moved into it. My way should avoid > changing the UNIQUENAME in the majority of cases. This causes exactly the problem you're trying to solve. When ports get moved to a new location, they are for all intents and purposes new ports. Using an origin-based UNIQUENAME makes the most sense and does the right thing for the common case. The issue here is that pkgng has problems with the MOVED format and wishes to tack on to UNIQUENAME to solve it's problem. The obvious solution here is to come up with a better MOVED format. Although, to me it isn't clear what the problem is. I doubt it's the MOVED file, it's probably more to do with ports that change their name based on dependency. If you really want to track a port even if it's changing locations, then you really should use some kind of GUID and provide a query interface for the set options -- which we already have. You could probably generate the GUIDs on port creation with an svn hook. > Remember that changing the UNIQUENAME changes where the record of the > port options are stored, and either we annoy a lot of users by making > them fill in a buch of dialogues all over again, or we have to invent > some complicated mechanism copy the old options settings to the new > directory. If you change the default and ensure it is unique by design, then migrating options for the user isn't that hard: OLDSCHEME=${PKGNAMEPREFIX}${PORTNAME} OLDOPTIONSFILE=${PORT_DBDIR}/${OLDSCHEME}/options .if exists(${OLDOPTIONSFILE}) _CONFIG_SEQ=migrate-config ${CONFIG_SEQ} .endif migrate-config: @${ECHO_CMD} "An options file has been found using the old" @${ECHO_CMD} " naming scheme. Would you like to migrate these" @${ECHO_CMD} " settings?" ...etc > Plus I think it would be more natural and easier for maintainers and > end-users to talk about (say) "phpmyadmin" rather than > "databases-phpmyadmin." I doubt UNIQUENAME is used in casual end user to maintainer conversations. :) -- Mel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FDC9A8B.2040701>