On Thu, Aug 25, 2005 at 06:15:36PM +0000, Dustin Spicuzza wrote:
> 
> >
> >Actually, I'd find it useful personally.
> >People add *weird* use flags sometimes.
> > 
> >
> LoL... yes, thats true.
> 
> A suggestion possibly to keep in mind is what if all functionality 
> related to USE flags were somehow implemented in a seperate class/set of 
> functions... or maybe that's already being done. But I mean, the job of 
> determining which flags apply to what package and managing all that and 
> how it works... I noticed that (at least in stable) a lot of it is in 
> portage.config, but maybe it could be a seperate class that 
> portage.config uses.. and other things (like deps, etc). Then stuff like 
> outputting USE flags, or adding additional ways to determine which USE 
> flags to actually use for each package, would all be in one location, 
> lending itself to code reuse...
> 
> Of course, this is just from my looking at portage stable for a week or 
> so... maybe its already being done. :)
It's being done :)
Essentially, you have this
config
domain
|--repo(s)
|  |--cache(s)
|  |--sync
|--vdb(s)
|--profile(s)

Domain is generated from configuration, as are all of the other 
objects; the config class just holds config data, and instantiates 
objects, shuffling them around dependant on an external file that 
states the rules for the config (in the process, stating how to 
instantiate the objs).

Config build data is domain data; your normal ebuild repository is an 
'unconfigured' repository, iow, you can toggle stuff on it to change 
the metadata of packages it returns.
The domain during instantiation notes that it has an unconfigured repo 
in it's list, inspects the repo instance for what is needed to 
configure it (and the func to call), calls the func with the 
configurables supplied, and uses the returned repo instead of the 
unconfigured repo.

Via this, the config data (USE, build, etc) is pushed down into the 
repo.  The configured repo wraps the unconfigured repo's returned 
packages with it's own wrapper that binds the config data into it, and 
hands that back.

Probably not a great description, but the short version is it works 
pretty well, and is pretty well encapsulated.

What I'd *like* to see is the use.{local.,}desc information bound into 
the repository, and have it supplied from the repository object; doing 
so keeps that data in the repo backend, not screwing up any 
abstractions that are carefully defined to allow for remote 
replacements.

Haven't proposed it to -dev yet, but I'd like to see package.* and 
use.* moved out of profiles/ , and into it's own base directory in the 
ebuild repository.
Reasoning is that profile objs are seperate from repo objs; the fs 
layout should reflect that to some degree.  It's cleaner anyways, imo. 
:)
~harring