Date: Sun, 17 Jun 2012 22:11:11 +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: <4FDE39DF.4090208@acsalaska.net> In-Reply-To: <20120617195109.GA1274@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> <4FDE2195.7090901@acsalaska.net> <20120617195109.GA1274@ithaqua.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17-6-2012 21:51, Baptiste Daroussin wrote:
> 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, 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 maintainer should avoid that before committing. No system can prevent bugs
>
>> 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.
>
> 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.
No. Ports all have a version starting with a minus sign, yet we have
ports with a minus sign in it. This is the same principle. The plus or
whatever char you pick, should be the first one from the right side
after the version part. What's in between the plus and the start of
version is subpackage/childport name.
>> 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
Hmm, agreed. Unless you fetch a mapping list. A guid would work for the
OPTIONS part, but not so well for this.
> It will also be very painful to generate all the guid for all existing ports.
But just once. Now you have work for all time to come, checking
uniqueness of uniquename.
>> 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.
Sometimes it's better to break things once, so you don't have to ever
again. But I guess that's something we should agree to disagree on.
--
Mel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FDE39DF.4090208>