public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Paul de Vrieze <pauldv@gentoo.org>
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] Categories
Date: Fri, 6 Jun 2003 18:35:34 +0200	[thread overview]
Message-ID: <200306061835.52352.pauldv@gentoo.org> (raw)
In-Reply-To: <3EDE00C4.6060201@helide.com>

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2191 bytes --]

On Wednesday 04 June 2003 16:23, Rolf Veen wrote:
> George Shapovalov wrote:
> > 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 :).
>
> Namespace orthogonal to categories.
>
> Categories change, as packages are being added; if a category has more
> that N (lets say 50, for example) entries it looses its usefullness.
> While browsing for packages it is natural to have some level of depth;
> two or tree levels of categories should be ok. Also a package can fit
> into more that one category. Let categories be a graph. A symlink
> hierarchy, for example.

Unfortunately CVS does not work well with symlinks, so this is not really an 
option. Also there is an advantage in being able to have one unique name for 
a package.

>
> But since categories are variable and somewhat arbitrary, don't let
> the basic system, the core algorithms, depend on them. So take a flat
> namespace for packages, resolving name conficts in the download (url
> to local dir) phase, adding the necesary information to the ebuild.

We need unique names. For me category/name is a good way, and certainly better 
than UID's (Like microsoft uses) as those are impossible to remember and easy 
to do wrong. Also we have a central repository, so we don't need to worry 
about clashes that much.

>
> Concluding, have a flat namespace for machine interaction, and an
> arbitrarily complicated category graph on top of that for user
> interaction.

Flat namespaces are actually slower in machine interaction. There are allready 
very many packages in portage currently. Thousands of entries in a directory 
is NOT fun to look at, or to search for a computer (albeight doable).

My suggestion would be an alias list simmilar to the virtuals list, but one 
that is not allowed inside ebuilds. In those ways packages can still be 
presented in multiple categories, while the aliasses do not interfere with 
the inner workings of portage.

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2003-06-06 16:35 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
2003-06-04 14:23   ` Rolf Veen
2003-06-06 16:35     ` Paul de Vrieze [this message]
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=200306061835.52352.pauldv@gentoo.org \
    --to=pauldv@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