Re: [gentoo-dev] Portage Subcategory Capabilities?

[George Shapovalov]

On Sunday 03 October 2004 22:34, Andrew Gaffney wrote:
> This has been brought up before in the past and been shot down, but I'll
> humor you. If support for this were to be added into Portage, there would
No it wasn't. Discussion just felt off without leading to any conclusion as it 
happens quite often. Well, actually such discussions were happening multiple 
times in the past and while in some it may have felt like "shot down" in 
others it even went as far as being added to portage-ng features list ;).

> be a few things to think about:
>
> 1) this will cause a performance hit no matter how it is done
> 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
Grouping both as they are basically the same.
Directory walker is a pretty standard piece of code discussed in many text 
books for various languages. Python has explicit support for some basic 
dirwalker functionality in its standard library. 

As for distinguishing: in prior discussions there were calls to go the 
opposite route and flatten namespace. That is to get rid of categories 
altogether and rely solely on search. Thus one approach would be to make one 
pass accumulating all package names and then work off that (store path to 
ebuild dir in the cache for example). However that may not be optimal as this 
will disallow duplicate package names (which we *have* irrespectively of 
whether this is good or bad). 

A simpler and more efficient approach may be to simply prepend path to package 
name, possibly substituting '/' with some other separator if that's a 
problem. This will give a flat list of effective package names (that include 
all their categorization) which may even simplify further processing. 
Actually having a separate pass may be even more of an advantage as portage 
works off its cache for the most part anyway and this cache is created 
server-side already. Thus this change might even speed things up :) (well, 
not really, but shouldn't cause significant performance degradation either).

Ebuilds will have to specify full category for each dependency with such 
approach, but that's a policy anyway..


> 3) the many additional directories would cause an 'emerge sync' to take
>     longer than it does now.
Khm, not really sure about this one. If it really becomes that bad there were 
ways discussed on improving syncing (cvsup or collating small files comes to 
mind, but that's a separate discussion).

> Basically, you'd be pissing everyone off with little benefit (except maybe
> to developer sanity). Keep in mind that I probably have absolutely no idea
I wouldn't call this a small benefit, considering that its not only 
developers' sanity at stake here, I am pretty sure users would appreciate a 
more sane portage structure as well :).

> what I'm talking about and nothing I say should be accepted as fact without
> verifying it elsewhere.
That's what we are trying to do :).

George


--
gentoo-dev@g.o mailing list