1 |
>>Both make sense, and app-editors/yudit & app-editors/yudit would |
2 |
>>also make sense. Instead of categories, ebuilds should have a |
3 |
>>CATEGORY variable. E.g. |
4 |
> |
5 |
> Portage support would be required to support deeper trees. |
6 |
|
7 |
Note that I'm not talking about trees at all. I'm talking about |
8 |
a flat list of ebuilds, where every ebuild belongs to several |
9 |
categories of different levels of specificity. |
10 |
|
11 |
> The problem |
12 |
> with symlinks is that we use CVS for our portage tree, |
13 |
|
14 |
I don't propose any symlinking. |
15 |
|
16 |
> I, too, would like to see support for a more heirarchical portage tree |
17 |
> in a future version of portage. |
18 |
|
19 |
I think a hierarchy, where every ebuild has a specific place in |
20 |
the tree, is a bad fit for portage or for any packaging system. |
21 |
One does need a taxonomy or controlled list of categories, but |
22 |
an ebuild can legitimately belong to many categories. |
23 |
|
24 |
As drobbins says, though, current portage code is tied to the |
25 |
category structure. Which is perfectly workable, really :) I |
26 |
just completely ignore the category, and use `emerge search` to |
27 |
find packages. It only bugs developers who have to decide & |
28 |
revise in which category to put a package. However, I'd like |
29 |
categories to become more useful for me as user. |
30 |
|
31 |
-- |
32 |
Jean Jordaan |
33 |
http://www.upfrontsystems.co.za |
34 |
|
35 |
|
36 |
-- |
37 |
gentoo-dev@g.o mailing list |