Disclaimer:
Don't mind that it starts off ranting. I actually like some
of the implementation ideas presented. Any discussion on my
dillusions of grandjeur or my inability to spell will get
you smited in a very not nice way.

> 1) Possibility to change ENV during building some packages.

I certainly hope you realize the depths to which people go to
make your life miserable when attempting to do support.

Something like this will happen:
	source /etc/profile

Which does something great to the users console, but will
probably have destructive results otherwise. Bugs will now
require you to review not only the settings that portage
reports, but you will also have to check every related script
that the user decides to make part of the build process.
Unless we ignore anyone using these features. Would be funny
in that bated, ironic-reversal kinda way.

If they decide to alias something, it will have an affect
IN THE BUILD. Portage makes a lot of effort to prevent
things like this right now. unsets + unalias, are a quick
example.

> 2) it should be automatic, no more definition of environment variables 
> and manual emerging packages. No more spaming /etc/make.conf with some 
> environment variables which correspond only to one package (RXVT_TERM, 
> for example)

The idea is that it takes effort. If it's not trivial, you have to
LEARN to make it work. Having super-easy things is great, but not
when it happens to make FIXING it super complicated, developers lose.

The single package variables are mostly new to me, thus I have no
opinion on them.

> 3) Solution must  be flexible and allow us to have not only 
> "per-package" variables set, but also define some general sets for 
> inclusion. For example if we want to build soft1,soft2,ans soft3 with 
> IFC, we really don't want to have 3 copies of something like:
> F77=ifc
> FC=ifc
> F90=ifc
> FFLAGS="-xN -ip"
> Moreover, when we will decide to change CPU, we will not need to edit 3 
> files and change -xN to -xP. We want to do it once. :)

Some of this might be nice. If you're going to make this kind of
effort, why not integrate it into the ebuild?

> 4) BTW, in such case it also not bad to have option to include something 
> like
> USE="ifc"
> into this environment, and it should be parsed in proper way. I hope 
> that this is clear. If we want to build something with IFC and set 
> proper variables, we really don't want to go and edit one more file 
> (/etc/portage/package.use). And we don't want to edit also two files, 
> when we will figure out that we like coming gfortran :)

Absolutely not. This violates portage's dep calculations and is
completely wrong. Please do not change any variables that are
READONLY inside of ebuild.sh after the depend phase.

> So, lets define our problem in more details:
> 1) Assume that default configuration of my system is
> GCC 3.4.1
> CFLAGS="-O2 -pipe" in /etc/make.conf
> LINGUAS="ru" in /etc/make.conf
> there is no defined ifc and icc USE flags in /etc/make.conf
> 
> 2) I have set of packages, that require something "extra"
> lam-mpi : want to compile with ICC, IFC
> blas-reference : want to compile with g77 and high optimization
> lapack-reference : want to compile with g77 and high optimization
> blas-atlas: want to compile with IFC, ICC
> lapack-atlas: want to compile with IFC, ICC
> xine-lib : want to compile with low-optimization for GCC
> open office : want to compile with LANGUAGE="RUSS" and GCC 3.3.4 and 
> low-optimization
> kde-i18n : want to have with LINGUAS="fr" and GCC 3.3.4
> rxvt : want to compile with RXVT_TERM=xterm
> octave : want to build with high-optimization for GCC
> 
> 
> so, what I see?
> Something like:
> 
> #cat /etc/portage/package.env
> lam-mpi: icc ifc
> blas-reference: g77high.env
> lapack-reference: g77high.env
> blas-atlas: ifc.env icc.env
> lapack-atlas: ifc.env icc.env
> xine-lib: GCC_lowopt.env
> openoffice: language_ru.env GCC_334.env GCC_lowopt.env
> kde-i18n: linguas_fr.env
> rxvt: rxvt.env
> octave: GCC_highopt.env
> 
> 
> #ls /etc/portage/env
> ifc.env
> ifc.env
> GCC_highopt.env
> GCC_lowopt.env
> rxvt.env
> linguas_fr.env
> language_ru.env
> GCC_334.env
> g77high.env
> 
> and
> #cat /etc/portage/env/icc.env
> CC=icc
> CXX=icc
> CFLAGS="-O2 -xN -noalign"
> CXXFLAGS=$CFLAGS
> USE="icc"
> 
> #cat /etc/portage/env/GCC_highopt.env
> CFLAGS="-O3 -ffast-math -funroll-all-loops -fmove-all-movables"
> 
> #cat /etc/portage/env/GCC_lowopt.env
> CFLAGS="-O1"
> 
> #cat /etc/portage/env/GCC_334.env
> CC=/usr/i686-pc-linux-gnu/gcc-bin/3.3/gcc
> g77=/usr/i686-pc-linux-gnu/gcc-bin/3.3/g77
> 
> And rest it similar.
> 
> Of course, it could be not so bad, to have option, to include name of 
> file with ENV, or just env, to not produce tens of files with one 
> variable, like RXVT_TERM="xterm"... There is seems to be two solutions:
> 1) just have second file with definitions, where not filenames, but 
> defined variables.
> 2) change syntax of /etc/portage/package.env in such way, that allow to 
> include both kind of records, filename and strict definition inline.
> something like
> openoffice: GCC_334.env GCC_lowopt.env -- LANGUAGE="RUSS"
> 
> 
> For the moment both solutions looks ugly for me. At least I can't 
> imaging simple and easy-to-understand syntax for package.env, which will 
> look nice and will parce without problems.
> 
> What do you think about?

Some of the ideas actually look trackable, which I happen
to like. Inline definitions of variables, I am not
particularly fond of.

If portage has a way to accurately track these files and
there is a way to avoid arbitary inclusion, then it might
be a lot more feasable.

Providing code would be nice too. An interface to track and
an interface whereby portage controls the inclusions.

I'm very much against out-of-file references.

Eh. That is all I have to say.
I'm going to go home and take a nap now.

--NJ