1 |
On Tuesday 03 June 2003 11:01, Sebastian Werner wrote: |
2 |
> net-www -> |
3 |
> - net-www-server (apache, cherokee, ...) |
4 |
> - net-www-plugins (netscape-flash, netscape-plugger, ...) |
5 |
> - net-www-modules (mode_dav, mod_gzip, ...) |
6 |
> - net-www-clients (epiphany, mozilla, opera, ...) |
7 |
So, are we finally getting serious about more than two levels of |
8 |
categorisation? |
9 |
|
10 |
I was watching related topics with interest lately and will try to summarise |
11 |
what has been said so far. If I am missing something, please do comment on |
12 |
it. |
13 |
|
14 |
Basically most of the related proposals were coming down to treating every |
15 |
categorisation level as a dir in order to enhance browsability of the tree. |
16 |
Thus we would get only a handfull top-level categories containing more |
17 |
subcategories, possibly containing more subcategories... Like in this case it |
18 |
would be /net/www/{server,plugins...}. |
19 |
|
20 |
Alternatively there was a question whether we may consider abandoning |
21 |
categorisation altogether and going with a flat namespace (and corresponding |
22 |
lack of categorisation), relying only on search capabilities. More on |
23 |
searches later.. |
24 |
The main objection to this was that categories are actually used and |
25 |
appreciated (by me included) since some people do browse the tree on |
26 |
occasions (its like library access. Sure you can search for pretty much |
27 |
everything, but somethimes nothing beats coming down to the shelves and |
28 |
finding what other books are neaby the one you were able to find). |
29 |
|
30 |
Other complications with such approach include high probability of name |
31 |
clashes in flat namespace (what we already do experience) and the fact that |
32 |
this indirectly contradicts the policy, which requires categories to be |
33 |
listed in [R|P]DEPEND statments.. |
34 |
|
35 |
One downside of purely tree-like structure that was mentioned is the |
36 |
difficulty of unambiguous categorisation of certain packages. Enhancement |
37 |
calls were made, such as the one below: |
38 |
> Another more advanced solution I think, is to handle categories |
39 |
> something like epiphany. "Add one or more categories to a application |
40 |
> and find it in all". We must move all apps out of there categories flat |
41 |
> in the main-directory - or eventually better in this case one new |
42 |
> created dir. |
43 |
|
44 |
I should probably leave it up to Nick to comment on implementation details, |
45 |
however my uderstanding is that it is really beneficial to have a tree-like |
46 |
structure for at least internal data representation, as it makes it easy to |
47 |
traverse and search by particular relation. If this inernal structure is |
48 |
usefull for browsing, so much the better. |
49 |
|
50 |
However the question of multiple logical placement still stands. It has been |
51 |
addressed in general by proposals to add some search keywords to ebuilds or |
52 |
package directory in some way. Well, KEYWORDS are already used (albeit for a |
53 |
different purpose, though IIRC (and I am not rally sure here) originally such |
54 |
use was considered as well, but I think it was decided to narrow the scope in |
55 |
order to avoid overloading it), but it may be possible to introduce some |
56 |
other var, say SEARCHKEYS and add database indexing by these keys |
57 |
functionality to portage (and naturally cache the index tables in addition to |
58 |
what is already being cached). This should allow portage tree to be treated |
59 |
like a "real" database and should cover the requirement of multiple logical |
60 |
adherence. |
61 |
|
62 |
One remark is possible here: that ebuilds themselves are probably not the |
63 |
ideal place for the SEARCHKEYS, as this information will be for the most part |
64 |
duplicated among all the different versions. It would make sence to store |
65 |
this informaation in some "central" to the package place and I seem to |
66 |
remember this mentioned as one of the proposed provisions of "enhanced" |
67 |
ChangeLog's discussed back quite some time.. |
68 |
|
69 |
Ok, this seems to be pretty much it, at least from what I remember being |
70 |
mentioned on this topic. Again, if anybody thinks I ommitted something, |
71 |
please stand up and mention it :). |
72 |
|
73 |
George |
74 |
|
75 |
|
76 |
|
77 |
-- |
78 |
gentoo-dev@g.o mailing list |