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 _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"