public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: George Shapovalov <george@gentoo.org>
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] Categories
Date: Tue, 3 Jun 2003 17:32:47 -0700	[thread overview]
Message-ID: <200306031732.48204.george@gentoo.org> (raw)
In-Reply-To: <3EDCE281.9030804@sebastian-werner.net>

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


  reply	other threads:[~2003-06-04  0:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-03 18:01 [gentoo-dev] Categories Sebastian Werner
2003-06-04  0:32 ` George Shapovalov [this message]
2003-06-04 14:23   ` Rolf Veen
2003-06-06 16:35     ` Paul de Vrieze
2003-06-09  7:30       ` Rolf Veen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200306031732.48204.george@gentoo.org \
    --to=george@gentoo.org \
    --cc=gentoo-dev@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox