| 1 |
On Thu, Aug 25, 2005 at 06:15:36PM +0000, Dustin Spicuzza wrote: |
| 2 |
> |
| 3 |
> > |
| 4 |
> >Actually, I'd find it useful personally. |
| 5 |
> >People add *weird* use flags sometimes. |
| 6 |
> > |
| 7 |
> > |
| 8 |
> LoL... yes, thats true. |
| 9 |
> |
| 10 |
> A suggestion possibly to keep in mind is what if all functionality |
| 11 |
> related to USE flags were somehow implemented in a seperate class/set of |
| 12 |
> functions... or maybe that's already being done. But I mean, the job of |
| 13 |
> determining which flags apply to what package and managing all that and |
| 14 |
> how it works... I noticed that (at least in stable) a lot of it is in |
| 15 |
> portage.config, but maybe it could be a seperate class that |
| 16 |
> portage.config uses.. and other things (like deps, etc). Then stuff like |
| 17 |
> outputting USE flags, or adding additional ways to determine which USE |
| 18 |
> flags to actually use for each package, would all be in one location, |
| 19 |
> lending itself to code reuse... |
| 20 |
> |
| 21 |
> Of course, this is just from my looking at portage stable for a week or |
| 22 |
> so... maybe its already being done. :) |
| 23 |
It's being done :) |
| 24 |
Essentially, you have this |
| 25 |
config |
| 26 |
domain |
| 27 |
|--repo(s) |
| 28 |
| |--cache(s) |
| 29 |
| |--sync |
| 30 |
|--vdb(s) |
| 31 |
|--profile(s) |
| 32 |
|
| 33 |
Domain is generated from configuration, as are all of the other |
| 34 |
objects; the config class just holds config data, and instantiates |
| 35 |
objects, shuffling them around dependant on an external file that |
| 36 |
states the rules for the config (in the process, stating how to |
| 37 |
instantiate the objs). |
| 38 |
|
| 39 |
Config build data is domain data; your normal ebuild repository is an |
| 40 |
'unconfigured' repository, iow, you can toggle stuff on it to change |
| 41 |
the metadata of packages it returns. |
| 42 |
The domain during instantiation notes that it has an unconfigured repo |
| 43 |
in it's list, inspects the repo instance for what is needed to |
| 44 |
configure it (and the func to call), calls the func with the |
| 45 |
configurables supplied, and uses the returned repo instead of the |
| 46 |
unconfigured repo. |
| 47 |
|
| 48 |
Via this, the config data (USE, build, etc) is pushed down into the |
| 49 |
repo. The configured repo wraps the unconfigured repo's returned |
| 50 |
packages with it's own wrapper that binds the config data into it, and |
| 51 |
hands that back. |
| 52 |
|
| 53 |
Probably not a great description, but the short version is it works |
| 54 |
pretty well, and is pretty well encapsulated. |
| 55 |
|
| 56 |
What I'd *like* to see is the use.{local.,}desc information bound into |
| 57 |
the repository, and have it supplied from the repository object; doing |
| 58 |
so keeps that data in the repo backend, not screwing up any |
| 59 |
abstractions that are carefully defined to allow for remote |
| 60 |
replacements. |
| 61 |
|
| 62 |
Haven't proposed it to -dev yet, but I'd like to see package.* and |
| 63 |
use.* moved out of profiles/ , and into it's own base directory in the |
| 64 |
ebuild repository. |
| 65 |
Reasoning is that profile objs are seperate from repo objs; the fs |
| 66 |
layout should reflect that to some degree. It's cleaner anyways, imo. |
| 67 |
:) |
| 68 |
~harring |
Archives