On Friday 30 May 2008 18:34:25 Ciaran McCreesh wrote:
> What would we use instead of categories, if we could replace them?
A package should be able to be in more than one category (so they'd be more
like tags than categories, really). Categories in Gentoo can indicate any of
* application domain (eg media-*, games-*, sci-*)
* programming language (all of dev-${LANGUAGE})
* desktop environment (eg kde-*, gnome-*, x11-*)
* "kind" of software (eg *-libs, *-plugins, *-apps)
and it's pretty arbitrary which of several relevant categories a package goes
in. Also, a single package can often fit in multiple places for each bullet
point (eg SeaMonkey can do web, mail, news and IRC; Paludis has both a set of
applications and a library callable from C++, Ruby and Python), so there
shouldn't be any restrictions on how tags can be combined.
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.
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 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.
_______________________________________________
Exherbo-dev mailing list
[email protected]
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
