[CFT] UNIQUENAME patches

Mel Flynn rflynn at acsalaska.net
Sat Jun 16 15:06:42 UTC 2012


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


More information about the freebsd-ports mailing list