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.
_______________________________________________
Exherbo-dev mailing list
[email protected]
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
