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@gentoo.org mailing list
