Re: [gentoo-dev] Re: New category proposal

[Brian Harring]

On Tue, May 10, 2005 at 08:04:04PM +0900, Georgi Georgiev wrote:
> maillog: 10/05/2005-11:28:21(+0200): Martin Schlemmer types
> > On Mon, 2005-05-09 at 13:07 -0400, Aron Griffis wrote:
> > > Georgi Georgiev wrote:	[Sun May 08 2005, 08:19:20PM EDT]
> > > > Would it be inappropriate to start bitching (again) about a flat
> > > > tree where each package can go in multiple categories?
> > >
> > > That's something I'd love to see eventually...  I mean the flat tree,
> > > not the complaining ;-)
> > >
> >
> > Problem with flat tree, is the search times might then suck even more,
> > as last I heard, too many dirs/files in one directory have a huge speed
> > penalty.
>
> The flat tree does not imply a flat hierarchy on disk. Files and
> directories can still be organized in a more optimized manner. For
> example -- put each package in a directory of its first letter. Maybe
> even two letters if you think that the winner 'g' with 736 packages is
> too many.
This would basically require a totally seperate rsync module for newer 
portage versions that would handle it.  Or portage would have to 
support both, which (frankly) is something of a no go; it's too 
fricking ugly imo.

Beyond that, drop the optimized manner in reference to speed; 
addressed below.  Optimized for human readability?  not so sure, 
digging through debian's directory structure to dig out certain files 
has always drove me slightly insane while doing so...


> This is only true when the portage tree is stored on a filesystem. I
> recall some effort being made in making portage support reading the
> portage tree from a zipfile, so we may eventually see some other
> backends that would not suffer from this problem.
Down the line, viable (should be able to basically go nuts in terms of 
how you store the tree, locally, remotely, etc).  Now?  eh, tiz a ways 
off.

Regarding speed comments about look up in the tree, frankly it's a bit 
minor imo.  Initial installed package scan is a heavier hit (it's 
required for even an emerge --help).  The bits in this thread about 
using xyz fs for the tree are trying to address the effects, not the 
cause of potentially slow cp_list/cp_all lookups; if the tree were 
marked as frozen (non-modifiable, iow users don't modify an ebuild 
here and there), and portage had frozen support (working on it), you 
could work directly from the cache instead, which would be a bit 
faster (at the very least, less syscalls, (open|close|read)dir, 
stat'ing, etc).

The speed portion of the arg in other words, I don't think is valid.  
Better to focus on what benefits the poor human who has to go digging 
through the tree manually, then try to make portage go faster via it 
w/ dir structuring/underlying fs.

Re: having a package claimed by multiple categories... eh.  yeah, 
that's a bit valid although I'd think it's either A) an indiciation 
our categories need to be adjusted a bit, or B) (hopefully) a rare 
case. :)

My 2 cents, at least.
~Brian
-- 
gentoo-dev@g.o mailing list