Re: "Environement categories" (was Re: [gentoo-dev] fix binary debug support, part elevenity billion 1/2)

[Brian Harring]

On Mon, Jan 23, 2006 at 07:28:05PM +0100, Danny van Dyk wrote:
> Donnie Berkholz schrieb:
> | Marius Mauch wrote:
> |>I meant the option is redundant if it just triggers a feature setting,
> |>as it's the same as `FEATURES=debug-build emerge foo`
> |
> | OK, where's my package.features and packages.cflags files then? I can do
> | what I want through Mike's proposal, which is to build a specific
> | collection of packages with debugging. I also don't need to duplicate
> | the same list of packages in one file with FEATURES=nostrip and in
> | another with debugging CFLAGS.
>
> I'd love to have one package.env (or similarly named) file that can set
> environmental options on a per-package-base. This is just a proposal,
> but i personally would like it this way:
>
> # First define a category of environmental options:
> stable=( \
> 	"ACCEPT_KEYWORDS=\"arch\"" \
> 	"CFLAGS=\"-pipe -O -march=foo\"" \
> )

We've already got package.keywords...
Not saying it's the best, but muddying up the existing configuration 
with N ways of saying the same thing imo isn't the sanest.

> debug=( \
> 	"FEATURES=\"debug-build keepwork\"" \

And there is the kicker.  Portage has globals, which are in various 
states of use- most of the features you're looking to tweak *are* 
effectively globals already.

So... you need seperate configuration instances.  This gets ugly since 
not all code uses a passed in config instance, some falls back to 
global access (just the same as not all code uses passed in dbapi's, 
they use the global portage.db).

The config representation does a nasty little dance where it pushes 
changes on, then pops them (moreso it just flat out regenerates the 
settings)- extending usage of that really isn't a good thing imo, 
since it's fundamentally the wrong design.  Hell, such an approach 
won't fly anyways for any real possibility of threaded execution 
(parallel-fetch doesn't count, it's a fork for exactly this reason).

See where I'm going with this, and why the portage crew occasionally 
make reference to design flaws? :)

Might I suggest this one just get shelved for a while?  I'm not much 
for spanky's proposal from an implementation side of things, but it 
skirts the areas I'm concerned about (thus I'm mostly neutral on it), 
but varying all configuration data per node is a whole different beast 
from spanky's proposal- it's not skirting the areas that are icky.

Realistically, need to design the bugger so configuration data is 
pushed down to each level/abstraction rather then a global obj; do 
that, and it's easy to vary settings per node; rewrite is designed 
this way, just not finished.

Personally, I'd rather revisit this a few months down the line- right 
now it's too nasty of a hack to even consider it in stable.


> This proposed format could even be more easily parsed when split into to
> files. One file to define the categories and one to define the
> package-to-category bindings. The first file would be pure bash and
> could be loaded like this:
>
> mycat=$(
> 	. ${CATEGORY_FILE}
> 	cat=${!cat}
> 	for i in $(seq 0 $(( ${#cat[@]} - 1)) ) ; do
> 		echo -e "${cat[${i}]}"
> 	done
> )

Bash side overrides are a no go; either the resolver would have to 
spawn a shell instance for processing each node, or portage would have 
to know how to parse and execute shell (hard... very hard).

So... at least the bash side of it, not really doable imo.  Same 
reason you can't use bashrc to affect features (for the most part), 
by the time that code is executed it's too late in the game.

~harring