Gentoo Archives: gentoo-dev

From: George Shapovalov <george@g.o>
To: gentoo-dev@g.o
Subject: Re: [gentoo-dev] Categories
Date: Wed, 04 Jun 2003 00:33:33
Message-Id: 200306031732.48204.george@gentoo.org
In Reply to: [gentoo-dev] Categories by Sebastian Werner
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

Replies

Subject Author
Re: [gentoo-dev] Categories Rolf Veen <rolf.veen@××××××.com>