On 00:12 Fri 08 Feb , Marius Mauch wrote: > On Thu, 7 Feb 2008 12:56:43 -0800 > Donnie Berkholz <[EMAIL PROTECTED]> wrote: > > > On 15:12 Wed 06 Feb , Alec Warner wrote: > > > On 2/4/08, Jonas Bernoulli <[EMAIL PROTECTED]> wrote: > > > > On 2/4/08, Donnie Berkholz <[EMAIL PROTECTED]> wrote: > > > > > On 20:11 Mon 04 Feb , Jonas Bernoulli wrote: > > > > > > Thinking about it again I would say tags and categories just > > > > > > fulfill different purposes. Tags can not replace categories > > > > > > but might be a useful extension to categories for the tasks I > > > > > > described, not more not less. They are not better or worse, > > > > > > just different:) > > > > > > > > > > Why don't you think they can replace categories? > > > > > > > > Quick answer: Because there are packages with the same name in > > > > different categories. How would tags deal with that? > > > > > > Techincally you could enforce UNIQUE(pkg,[tags]), I agree thats a > > > poor constraint though ;) > > > > I would probably print the ambiguous package name, with info on each > > package, and a list of tags unique to each that could be used to > > specify which one you want. Perhaps a numbered list too. > > That only works for the user interface, not so good for depend strings, > config files and pretty much everything else.
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). 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. Thanks, Donnie -- [email protected] mailing list
