-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 8, 2008 7:32 AM, Donnie Berkholz wrote: > I don't think categories are the best way of resolving ambiguities, > because they don't uniquely identify a package. One could imagine two > packages in the same category with the same name (for example, two > Python modules that do drastically different things but would go in > dev-python).
In my humble opinion, the current classification is perfectly fine in practice -- it is quite similar to the human naming system: , => / (okay, not exactly -- categs are limited -- but close enough) Surely there are more humans than packages, but we do fine don't we? :) And wherever there is a chance of conflict, we created aliases. This system of classification appeals to my common sense. If there are two packages with the same name in the same "general category", say, for example, perl/python modules/libraries, there will be confusion between them in the real world anyway, and one of them will *have* to change their name to prevent it. Off my head, I can think of pkgconfig crashing and burning if it got involved in such a dispute :^) > > I'm not sure what the best way is, but I don't think it's categories. > Perhaps some sort of UUID for packages? You could treat unique tags like > categories, but those could also be duplicated. I really don't think this needs such complicated solutions; especially when the "problem" is actually more of an enhancement to the category system, and the "solution" will complicate more than it will alleviate. Let's not forget that most package/dependency management systems (pkgconfig, PackageKit[?], dpkg, rpm, etc) make do with just one name-space -- staying one step ahead should be enough ;) - -- ~Nirbheek Chauhan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: http://firegpg.tuxfamily.org iD8DBQFHrCWZb1z91vbKYbYRAq7AAJ96IukPElYbcamfct32NLbsRCZUjQCgxh1X JonN+76MwRb5D06b8ZWghjE= =TwMR -----END PGP SIGNATURE----- -- [email protected] mailing list
