On Sun, 28 Oct 2012 13:38:01 +0100
Bernd Steinhauser <[email protected]> wrote:

> Then we could just stay with what we have right now. I basically
> proposed the subprovider thing, because it introduces a very natural
> structure for quite a few larger projects (like i.e. gnome, kde),
> that's all.

In fact, the point is why we should use '/' instead of '-' for
subproviders, subcategories or whatever? Taking into account number of
categories (any style), i should consider that there ain't any reasons
to make another fs hierarchy level. Moreover, assuming we have
suggested provider-based categories, this may end with non-consistent
hierarchy: three levels down to exheres for big providers, two level
for small – not very usable for shell scripting and same stuff.

Just as example:

 find /var/db/paludis/repositories/arbor/packages/ -maxdepth 2
 -mindepth 2 | sed -e 's,/, ,g' | awk '{print $8}'

will print all package names for arbour,

 find /var/db/paludis/repositories/*/packages/ -maxdepth 2 -mindepth 2 |
 sed -e 's,/, ,g' | awk '{print $8}'

will do the same for all installed repositories (i know that it can be
optimized, yes ;)). How long would be such one-liner for mixed-depth
hierarchy?

> And I really dislike them, because they are both unprecise and
> limited.

They are limited, indeed. But provider-based cats, while surely being
precise, seem unusable for me.

Let's speak practically: what provider could be set for Midori web
browser? xfce.org/misc, xfce.org/network, xfce.org/goodies,
xfce.org/browsers, or twotoast.de? I hardly would search Midori in any
of these categories, so i'ld need some sort of searching (by keyword,
by tag, by resolve – doesn't matter).

Another practical problem: ambiguous names. Consider we have a web
browser blah and text editor blah. In current system i can with zero
efforts consider that i need www-net (or maybe www-client) one, not
app-text. In provider-based system how on the earth can i see what do i
need: sourceforge/blah or googlecode/blah? Look up package
description/keywords?

If i'ld need searching for almost every package (except parts of gnome
or kde, almost none of them i've installed manually) why do i need any
categorization ever? Maybe it'll be better to place packages to
alphabetical directories, like p/py/pyopenssl? Most precise, simple and
unambiguous way i can imagine.

Graphical representation of role-based/provider-based
categories difference:

http://img404.imageshack.us/img404/3489/screenshotmenu.png (role-based)

vs

http://cdn.teknobites.com/wp-content/uploads/2009/04/vistastartmenu.jpg
(provider-based)

> Quite often, it is unclear where to put a package and
> sometimes, a package can be put into different "categories",
> depending mainly on the mood of the committer. Right now, we have for
> example two categories for web browsers, one being net-www, the other
> one www-client. And at some point, someone might want to put them
> into web-browsers.

There is ambiguity, yes. I should say that gentoo has near zero
similar problems and 95% of exherbo's categorization problems are
legacy ones (like inherited www-client versus modern net-www).

I think that we do need standards and agreements for this, and don't
need incompatible breakage of whole system.

> In the end, the gentoo-style categories are very
> close to being useless to categorize stuff, tags (or whatever you
> want to call them, I prefer keywords) are much better suited to do
> that.

Yes, when (and if) we'll have good exheres tagging system (which depends
more on package maintainers efforts then on paludis code), we will be
free to break categorization to the hell (although i like shell
scripting and cannot see why we need this breakage).

> Although far from being perfect, I think that the provider is a
> more precise way to structure the exheres tree.

I think this is pretty subjective... But i want to listen other's
opinions as well.


_______________________________________________
Exherbo-dev mailing list
[email protected]
http://lists.exherbo.org/mailman/listinfo/exherbo-dev

Reply via email to