From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32017 invoked by uid 1002); 4 Jun 2003 00:33:33 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 11612 invoked from network); 4 Jun 2003 00:33:33 -0000 From: George Shapovalov Organization: Gentoo Linux To: gentoo-dev@gentoo.org Date: Tue, 3 Jun 2003 17:32:47 -0700 User-Agent: KMail/1.5.2 References: <3EDCE281.9030804@sebastian-werner.net> In-Reply-To: <3EDCE281.9030804@sebastian-werner.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200306031732.48204.george@gentoo.org> X-Spam-Status: No, hits=-2.5 tagged_above=-100000.0 required=5.0 tests=EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_KMAIL X-Spam-Level: Subject: Re: [gentoo-dev] Categories X-Archives-Salt: b46940bc-ede8-418d-9b54-51b098253d1b X-Archives-Hash: b3b77b5de25c55b1e46c1a7574c39ba0 On Tuesday 03 June 2003 11:01, Sebastian Werner wrote: > net-www -> > - net-www-server (apache, cherokee, ...) > - net-www-plugins (netscape-flash, netscape-plugger, ...) > - net-www-modules (mode_dav, mod_gzip, ...) > - net-www-clients (epiphany, mozilla, opera, ...) So, are we finally getting serious about more than two levels of categorisation? I was watching related topics with interest lately and will try to summarise what has been said so far. If I am missing something, please do comment on it. Basically most of the related proposals were coming down to treating every categorisation level as a dir in order to enhance browsability of the tree. Thus we would get only a handfull top-level categories containing more subcategories, possibly containing more subcategories... Like in this case it would be /net/www/{server,plugins...}. Alternatively there was a question whether we may consider abandoning categorisation altogether and going with a flat namespace (and corresponding lack of categorisation), relying only on search capabilities. More on searches later.. The main objection to this was that categories are actually used and appreciated (by me included) since some people do browse the tree on occasions (its like library access. Sure you can search for pretty much everything, but somethimes nothing beats coming down to the shelves and finding what other books are neaby the one you were able to find). Other complications with such approach include high probability of name clashes in flat namespace (what we already do experience) and the fact that this indirectly contradicts the policy, which requires categories to be listed in [R|P]DEPEND statments.. One downside of purely tree-like structure that was mentioned is the difficulty of unambiguous categorisation of certain packages. Enhancement calls were made, such as the one below: > Another more advanced solution I think, is to handle categories > something like epiphany. "Add one or more categories to a application > and find it in all". We must move all apps out of there categories flat > in the main-directory - or eventually better in this case one new > created dir. I should probably leave it up to Nick to comment on implementation details, however my uderstanding is that it is really beneficial to have a tree-like structure for at least internal data representation, as it makes it easy to traverse and search by particular relation. If this inernal structure is usefull for browsing, so much the better. However the question of multiple logical placement still stands. It has been addressed in general by proposals to add some search keywords to ebuilds or package directory in some way. Well, KEYWORDS are already used (albeit for a different purpose, though IIRC (and I am not rally sure here) originally such use was considered as well, but I think it was decided to narrow the scope in order to avoid overloading it), but it may be possible to introduce some other var, say SEARCHKEYS and add database indexing by these keys functionality to portage (and naturally cache the index tables in addition to what is already being cached). This should allow portage tree to be treated like a "real" database and should cover the requirement of multiple logical adherence. One remark is possible here: that ebuilds themselves are probably not the ideal place for the SEARCHKEYS, as this information will be for the most part duplicated among all the different versions. It would make sence to store this informaation in some "central" to the package place and I seem to remember this mentioned as one of the proposed provisions of "enhanced" ChangeLog's discussed back quite some time.. Ok, this seems to be pretty much it, at least from what I remember being mentioned on this topic. Again, if anybody thinks I ommitted something, please stand up and mention it :). George -- gentoo-dev@gentoo.org mailing list