[Exherbo-dev] That categories thing again...

Bernd Steinhauser exherbo at bernd-steinhauser.de
Tue Oct 30 17:59:06 UTC 2012

On 30/10/12 04:39, matimatik wrote:
> 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.
Apart from what Ciaran wrote, it's also what I wrote in my original email, that 
it might provide advantages, when it comes to package splits.
But I mainly thought about this because of the number of packages per directory 
ratio, so if that's not a problem, I don't care too much.

>   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?
Short answer: Don't do that.
That's exactly why Paludis has bindings and APIs. And for what you are doing, 
cave provides better ways itself anyway...

The part you didn't understand is that what I wrote about is only about the 
structure of package tree in the filesystem (or actually the repository). Of 
course it should be easily accessible by developers, because they need to edit 
the exheres and specify deps, but it does not have to be easy accessible for 
shell script modification. This is not and probably never will be a criterion 
for the package tree.
> 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).
I don't know what Midori is, but if it is not assigned to a project upstream, I 
would indeed move it to xfce.org/ (or xfce/). That's also what I wrote about in 
my first email, that it might be likely, that both 2-level and 3-level 
structures might exist within the same provider. If both are allowed, I don't 
see a reason why they shouldn't coexist within a provider.
> 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?
Oh yes, for sure. If you don't do that and I find out about that, you will 
definitely get stabbed by me. If you are not sure about a dependency, the worst 
thing you can do is to assume that it is "that one". If we can get people to 
ensure that they are using the right dependencies by using this method, that's 
actually a good reason for it, in my opinion.
Apart from that, quite often, upstream tells you which dependency they mean, 
often even within the build system (it's very common for cmake, for example). 
Normally, you get a name, a version, a description and a homepage, which is 
quite often similar to the provider or at least leads to it.

Problems may come up with providers like sourceforge or github, where quite 
often only the sourcecode is hosted, so that could lead to confusion, especially 
for different implementations of the same thing.
> 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.
It's not like that idea is new, and you can be sure that it has been discussed. 
The problem here is that packages which share the same name (raptor comes to my 
mind) can not be separated in a clean way.
> 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)
See above, it's not about user usability at all. There are other ways to take 
care of that part in a much more advanced way.

Overall, I'm kind of sad that nobody seems to think about any of the more 
technical things mentioned, like the package moves, splits etc. Especially, 
because these parts could be useful even for approaches.

More information about the Exherbo-dev mailing list