Re: [gentoo-dev] Portage Subcategory Capabilities?

[Robin H. Johnson]

On Mon, Oct 04, 2004 at 12:34:50AM -0500, Andrew Gaffney wrote:
> 1) this will cause a performance hit no matter how it is done
A performance hit yes, but a lot less of a performance hit than you
might expect, provided one requirement is met:
- A directory cannot be both a category and a package ever. (This means
  no renaming packages to categories too).

> 2) how will Portage know the difference between a package and another
>    sub-category when it is walking the tree? It could do something
>    like walking all the way to the end of the
>    category/sub-category/sub-category tree until it finds .ebuild
>    files and then backing up a level or 2 to determine the category,
>    but again this would cause an enormous performance hit due to the
>    additional required I/O.
Portage already has an explicit list of all valid categories that it
uses to check paths (see profiles/categories). Simply split the provided
package atom into two components by looking for the very last slash.
That gives you (category,pn), which can then be verified for existence
by comparing the category against the list, and then checking it's
directory for the package name. I believe it works in a very similar
fashion to this already.

> 3) the many additional directories would cause an 'emerge sync' to take
>    longer than it does now.
Rsync would not be the bottleneck, and performance would actually
improve on any system that has trouble coping with very large numbers of
files in a single directory. Go and time 'ls' in your $DISTDIR. None of
our package directories have reached that point yet, but I sincerely
hope they never do.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@××××××××××××××.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85