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 $(( [EMAIL PROTECTED] - 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
pgpZMabwXoRwB.pgp
Description: PGP signature
