> There should also be some kind of hierarchy between tags, with the potential > to be arbitrarily deep (even though most packages will probably use only one > or two levels), so we can have, say, a dev/tool/scm/git tag for all > git-related software, or games/roguelike/nethack for all NetHack derivatives. > > The package manager should probably be aware of the hierarchy, so a search > for dev/tool/scm will find all dev/tool/scm/git automatically.
I personally don't see the need for hierarchy when using tags. If you want all tools related to git, search on the tags 'tool' and 'git'. Having an hierarchy will in some way lead to the same issues a category based approach gives. > This would leave tags as metadata, rather than part of the identity of the > package as categories are now. As far as I know that's what happens in Ubuntu too. Packages seem to have some kind of category, but as far as I know (I'm not much of an Ubuntu user) that's not involving anything more than metadata. Seems like a great idea to me (no categories, metadata only). > 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. The hard part about finding the right package is to tell the package manager which one you've chosen. If it's just a package name that identifies a package, then the identification has to be extended to allow to differentiate between two equally named packages. Personally I think in these days every package has it's own place on the net, so that could be used as an unique identifier... Still sounds a bit sucky but that's MY best idea. > > I was thinking about some kind of generalised 'paths' API for Paludis... > > What all would it need to do? > > That doesn't sound relevant to what I just said, although it might be useful > in future for package systems that have a strict hierarchy but more deeply > nested than with ebuilds. I think it only needs to point to a package directory. If you want real hierarchy then maybe an extra database (instead of the filesystem as a database) could be useful. Regards, Michael Croes _______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
