On Fri, 30 May 2008 18:56:31 +0100 David Leverton <[EMAIL PROTECTED]> wrote: > This would leave tags as metadata, rather than part of the identity > of the package as categories are now. There would need to be some > other way to disambiguate between packages with the same upstream > name (but categories suck for that anyway, because it assumes that > the two packages won't go in the same category, although it's > plausible that there could be two dev-libs/libfoo or kde-misc/kbar). > I'm not sure what that would be, exactly; the only thing that comes > to mind is renaming one or both of the packages, but that's pretty > nasty, so if someone thinks of something better I'd be all for it.
I was thinking about having a single canonical path and a number of alias paths. What's currently CategoryNamePart would become PartialPath, and QualifiedPackageName would become FullPath. An ID would have a single preferred FullPath, but queries would also find an ID by any aliases. If we go that route... A few issues: * Should an ID be able to enumerate its non-preferred FullPaths? I'd be inclined to say no, since it'd probably be a full tree scan... * Clients would probably have to avoid displaying the same thing twice (e.g. querying */blah could find libs/x11/blah and libs/c++/blah). But this gets to be a pain in the ass if different repositories do different aliases. * Once something's installed, how will it 'remember' all its aliases so that deps upon libs/x11/blah and libs/c++/blah both find it? So paths probably aren't enough... -- Ciaran McCreesh
signature.asc
Description: PGP signature
_______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
