From owner-freebsd-ports@FreeBSD.ORG Sun Jun 17 19:51:12 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3A52106564A; Sun, 17 Jun 2012 19:51:12 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A185C8FC18; Sun, 17 Jun 2012 19:51:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5HJpCHM008900; Sun, 17 Jun 2012 19:51:12 GMT (envelope-from bapt@freebsd.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5HJpCTW008859; Sun, 17 Jun 2012 19:51:12 GMT (envelope-from bapt@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@freebsd.org using -f Date: Sun, 17 Jun 2012 21:51:09 +0200 From: Baptiste Daroussin To: Mel Flynn Message-ID: <20120617195109.GA1274@ithaqua.etoilebsd.net> References: <4FD8AFEC.6070605@FreeBSD.org> <4FDC9488.2010509@FreeBSD.org> <20120616145341.GK98264@ithaqua.etoilebsd.net> <4FDCA0FC.3050407@acsalaska.net> <20120616151125.GL98264@ithaqua.etoilebsd.net> <4FDE2195.7090901@acsalaska.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <4FDE2195.7090901@acsalaska.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Chris Rees , Matthew Seaman , freebsd-ports Subject: Re: [CFT] UNIQUENAME patches X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2012 19:51:12 -0000 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 17, 2012 at 08:27:33PM +0200, Mel Flynn wrote: > On 16-6-2012 17:11, Baptiste Daroussin wrote: > > On Sat, Jun 16, 2012 at 05:06:36PM +0200, Mel Flynn wrote: > >> On 16-6-2012 16:53, Baptiste Daroussin wrote: > >>> On Sat, Jun 16, 2012 at 03:13:28PM +0100, Matthew Seaman wrote: > >>>> On 16/06/2012 14:18, Chris Rees wrote: > >>>>> That's great-- though rather than patching colliding-only ports, ca= n't > >>>>> we just add the category to it? > >>>>> > >>>>> .for cat in ${CATEGORIES} > >>>>> UNIQUEPREFIX?=3D ${cat} > >>>>> .endfor > >>>>> > >>>>> (copying the code from PKGCATEGORY; might be better off moving the > >>>>> PKGCATEGORY code up higher and just using that). > >>>> > >>>> Yes. I thought long and hard about doing that, but I opted not to f= or > >>>> two reasons: > >>>> > >>>> 1) Using the port name + a uniqueprefix where necessary produces = what > >>>> is close to the minimal change required to give every port a > >>>> unique name. The UNIQUENAME won't actually change for quite a > >>>> lot of ports under my scheme. > >>>> > >>>> 2) As a way of future-proofing against reorganizations of the por= ts > >>>> 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. > >>>> > >>>> 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. (Yes -- this sort of thing will occur with the changes as > >>>> written. It can't be avoided entirely.) > >>>> > >>>> Plus I think it would be more natural and easier for maintainers and > >>>> end-users to talk about (say) "phpmyadmin" rather than > >>>> "databases-phpmyadmin." > >>>> > >>>> Cheers, > >>>> > >>>> Matthew > >>>> > >>>> --=20 > >>>> Dr Matthew J Seaman MA, D.Phil. > >>>> PGP: http://www.infracaninophile.co.uk/pgpkey > >>>> > >>>> > >>>> > >>>> > >>> > >>> I'm strongly against adding something related to the category automat= ically. > >>> Because I'm thinking about binary managerment, adding PKGCATEGORY to = uniquename > >>> would mean a package tracking will be lots in case of moving a port f= rom a > >>> category to another. Currently in pkgng a package is identified by it= s origin > >>> and thus can't survive automatically from a move, because origin chan= ges. > >> > >> You should solve this using a better index format. I figured out years > >> ago that the INDEX format used by the ports system is not a good format > >> for binary upgrades. > >> > >> > >> > >> > >> --=20 > >> Mel > >=20 > > Before saying that you should have a look at what pkgng is. pkgng doesn= 't give a > > shit about index. and changing the INDEX won't solve that if you have n= o way > > unique way to identify a package you are doomed, have a look at every s= ingle > > package management system in the world, all of the sane one with real b= inary > > management system have a unique way to identify packages. We don't ! >=20 > And you won't with this patch. Guess I should've explained myself > better. Here's your worst case scenario: > www/apache3 hits the ports tree. There's a typo in the UNIQUENAME making > it equal to apache2's uniquename. pkgng now happily concludes that > www/apache2 moved it's origin and end users get upgraded to apache3. If > you think people bitch about their lost option settings, see how happy > they are when this happens. >=20 The maintainer should avoid that before committing. No system can prevent b= ugs > The point isn't the INDEX, the point is that if the information you need > isn't available, you fetch it. If you can't count on /usr/ports/MOVED > being available locally, then make it available on the package server > and fetch it. If it doesn't have the information you need, then change > the format. >=20 > Also, we *do* have a unique identifier for a package. It's enforced by > the filesystem. This doesn't change with the childports. Each child port > only applies to one port origin. So the combination of PORTORIGIN + > CHILDPORTNAME is UNIQUE! >=20 > What this patch does, is a classic example of patching the patch instead > of fixing the problem. If you're going to base critical operations on > the base that something is unique, then you /have/ to ensure that it is > unique by design, not by human intervention. >=20 > Also, there's a discussion going on at hackers about the lack of > resources for the project. And here we are: the proposed fix requires > people to check up on other people and devoting computing time to > automate some of that process. >=20 > I really don't see what the problem is with setting uniquename to: > ${PORTORIGIN:S,/,__,}+${CHILDPORTNAME} > or: > databases/mysql55+server > databases/mysql55+client > etc. And so you want to forbid + as a character for PORTNAME? So you would need = to fix all the ports having a + in the name. >=20 > Or using a GUID that is checked against a masterlist and assigned > automatically on port creation if you wish to be able to track a port's > movement through the tree. That could be a better option, but not really userfriendly when it comes to= say pkg install $guid It will also be very painful to generate all the guid for all existing port= s. > So, my problem with this patch is that it doesn't address the issue, it > temporarily masks the issue at the advantage that users don't get option > boxes they've already filled out. Matt's work notwithstanding, it > shouldn't be the final solution to the problem. I think it is the best solution a fix an issue we currently have without breaking to much things. regards, Bapt --9amGYk9869ThD9tj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/eNS0ACgkQ8kTtMUmk6Ez0uQCfbin1RKTUo4NH6M+txa1n4Tb7 B1EAmgNIWi6MRrjjxkBlh8sLtUE3UL1I =eeVQ -----END PGP SIGNATURE----- --9amGYk9869ThD9tj--