Date: Sun, 17 Jun 2012 20:27:33 +0200 From: Mel Flynn <rflynn@acsalaska.net> To: Baptiste Daroussin <bapt@freebsd.org> Cc: Chris Rees <crees@freebsd.org>, Matthew Seaman <matthew@freebsd.org>, freebsd-ports <freebsd-ports@freebsd.org> Subject: Re: [CFT] UNIQUENAME patches Message-ID: <4FDE2195.7090901@acsalaska.net> In-Reply-To: <20120616151125.GL98264@ithaqua.etoilebsd.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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, can't
>>>>> we just add the category to it?
>>>>>
>>>>> .for cat in ${CATEGORIES}
>>>>> UNIQUEPREFIX?= ${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 for
>>>> 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 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.
>>>>
>>>> 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
>>>>
>>>> --
>>>> Dr Matthew J Seaman MA, D.Phil.
>>>> PGP: http://www.infracaninophile.co.uk/pgpkey
>>>>
>>>>
>>>>
>>>>
>>>
>>> I'm strongly against adding something related to the category automatically.
>>> 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 from a
>>> category to another. Currently in pkgng a package is identified by its origin
>>> and thus can't survive automatically from a move, because origin changes.
>>
>> 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/187796.html>;
>>
>>
>> --
>> Mel
>
> 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 no way
> unique way to identify a package you are doomed, have a look at every single
> package management system in the world, all of the sane one with real binary
> management system have a unique way to identify packages. We don't !
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.
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.
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!
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.
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.
I really don't see what the problem is with setting uniquename to:
${PORTORIGIN:S,/,__,}+${CHILDPORTNAME}
or:
databases/mysql55+server
databases/mysql55+client
etc.
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.
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.
--
Mel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FDE2195.7090901>