Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Jun 2012 21:51:09 +0200
From:      Baptiste Daroussin <bapt@freebsd.org>
To:        Mel Flynn <rflynn@acsalaska.net>
Cc:        Chris Rees <crees@freebsd.org>, Matthew Seaman <matthew@freebsd.org>, freebsd-ports <freebsd-ports@freebsd.org>
Subject:   Re: [CFT] UNIQUENAME patches
Message-ID:  <20120617195109.GA1274@ithaqua.etoilebsd.net>
In-Reply-To: <4FDE2195.7090901@acsalaska.net>
References:  <4FD8AFEC.6070605@FreeBSD.org> <CADLo83-Pr5Qqa6oUFKmfbLuuDOCiDQoiLVvjPfvJ1fT8ou0h9g@mail.gmail.com> <4FDC9488.2010509@FreeBSD.org> <20120616145341.GK98264@ithaqua.etoilebsd.net> <4FDCA0FC.3050407@acsalaska.net> <20120616151125.GL98264@ithaqua.etoilebsd.net> <4FDE2195.7090901@acsalaska.net>

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

--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.
> >>
> >> <http://lists.freebsd.org/pipermail/freebsd-questions/2008-December/18=
7796.html>
> >>
> >>
> >> --=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--



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