Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 44796 - [PATCH] Per package environment variables
Summary: [PATCH] Per package environment variables
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: High enhancement with 1 vote (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: InVCS
: 51023 51061 60891 66020 76684 82189 86722 88311 89890 97750 105199 111328 111458 119830 139182 141698 143264 155821 180748 192699 320457 (view as bug list)
Depends on:
Blocks: 335925
  Show dependency tree
 
Reported: 2004-03-15 19:33 UTC by Leonid Kabanov
Modified: 2011-09-03 06:30 UTC (History)
43 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
portage.py patch against portage-2.0.53_rc7 (patch,3.14 KB, patch)
2005-11-03 06:36 UTC, Nguyen Thai Ngoc Duy (RETIRED)
Details | Diff
Integrated setenv into setcpv (package-env.patch,2.94 KB, patch)
2005-11-03 07:17 UTC, Jason Stubbs (RETIRED)
Details | Diff
New patch for portage v2.1-r1 (portagev2.patch,4.39 KB, patch)
2006-06-29 13:07 UTC, Matteo Sasso
Details | Diff
Updated patch for 2.1.1_pre5-r2 (package-env,3.09 KB, patch)
2006-08-20 10:17 UTC, Harald van Dijk (RETIRED)
Details | Diff
Per-package bashrc support (0001-Support-per-package-bashrc-files-in-etc-portage-env-.patch,4.03 KB, patch)
2010-04-22 17:52 UTC, Michał Górny
Details | Diff
Helper patch to profile.bashrc (profile.bashrc.diff,830 bytes, patch)
2010-04-22 17:53 UTC, Michał Górny
Details | Diff
Per-package bashrc support (with missing unset added) (0003-Support-per-package-bashrc-files.patch,4.88 KB, patch)
2010-04-23 22:06 UTC, Michał Górny
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Leonid Kabanov 2004-03-15 19:33:47 UTC
Some packages require environment variables for tuneup emerging. For example:

alsa-drivers use ALSA_CARDS 
kde-i18n require LINGUAS (without this var it even don't fetch sources, whole emerging stops on this package)
amanda use AMANDA_CONFIG_NAME AMANDA_DBMODE AMANDA_GROUP_GID AMANDA_GROUP_NAME AMANDA_PORTS AMANDA_PORTS_BOTH AMANDA_PORTS_TCP AMANDA_PORTS_UDP AMANDA_SERVER AMANDA_SERVER_INDEX AMANDA_SERVER_TAPE AMANDA_TAR_LISTDIR AMANDA_TMPDIR AMANDA_USER_GROUPS AMANDA_USER_HOMEDIR AMANDA_USER_NAME AMANDA_USER_SH AMANDA_USER_UID (!!!)

This list is far from complete. 

Sometimes I want to tuneup `myconf', `USE' and `CFLAGS' variables for some packages. So request: use file for setting some env vars per package (or may be eclass). It's syntax:

# comment
mask:ENV=foo

where `mask' is just substring of package name.  Simple example of this file:

# compile ymfpci driver only
media-sound/alsa-driver:ALSA_CARDS="ymfpci"
# using russian translation for kde-i18n (kde3 only)
kde-base/kde-i18n-3:LINGUAS="ru"
# passing `--enable-final' to `configure' for kdebase-3.1* and kdelibs-3.1*
kde-base/kdebase-3.1:myconf='--enable-final'
kde-base/kdelibs-3.1:myconf='--enable-final'
# we don't want java bindings for berkeley db-4.1.*
sys-libs/db-4.1:USE='-java'

This syntax very easy and file can be parsed and used even in shell. Also `mask' can contain wildcards like `kde-base/kde*-3.2.1' or even regexp (if it's not too hard to implement).
Comment 1 Marius Mauch (RETIRED) gentoo-dev 2004-03-15 22:11:54 UTC
You want to read about /etc/portage/package.use and /etc/portage/bashrc in `man portage`.
Comment 2 SpanKY gentoo-dev 2004-08-19 20:53:50 UTC
*** Bug 60891 has been marked as a duplicate of this bug. ***
Comment 3 SpanKY gentoo-dev 2004-08-20 17:27:50 UTC
*** Bug 60891 has been marked as a duplicate of this bug. ***
Comment 4 Seemant Kulleen (RETIRED) gentoo-dev 2004-08-21 02:56:06 UTC
reopening, at aye's request
Comment 5 Marcin Kryczek (RETIRED) gentoo-dev 2004-08-21 03:03:17 UTC
currently it's impossible to declare C*FLAGS for individual packages. i would like to have some base system, which can be executed on both - intel and amd procesors, but i would also like to have the rest of programs compiled with opmimalization for my cpu. 
my proposition is to add some additional file into /etc/portage/ to make such possibility. what do you think of it?
i've wrote bug #60891 about it, but it's marked as duplicate of this one.
Comment 6 Leonid Kabanov 2004-08-22 19:58:23 UTC
As I mentioned above there a lot of environment vars those affect emerging process. There is no possibilities to setup CFLAGS or myconf per package. `LINGUAS' variable must be setted to different values for openoffice and kde-i18n. 
I suggest adding something like package.env in /etc/portage with this functionality. 
Comment 7 Anton Starikov 2004-08-31 15:51:11 UTC
[here is copy of my mail form gentoo-dev list]

OK, lets develop discussion about option to choose environment variables per-package (compiler, flags and not only).

As some of us know, definition of problem already include 90% solution. So, lets start from user-side.
Want we want to see?
1) Possibility to change ENV during building some packages.
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)
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. :)

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 :)

5) even more. I'll start not with per-package basic, but with per-environment basic, as a first iteration.

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
lapack-reference g77high
blas-atlas ifc icc
lapack-atlas ifc icc
xine-lib GCC_lowopt
openoffice language_ru GCC_334 GCC_lowopt
kde-i18n linguas_fr
rxvt rxvt
octave GCC_highopt


#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.
This syntax can be added to the current portage extremely easy. Just less than 10 lines of code. I can make even a patch fo testers.



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 parse without problems. 
Comment 8 Leonid Kabanov 2004-08-31 18:26:51 UTC
The second solution can be changed that way:

category/program: GCC_334.env myconf='--enable-foo --without-bar' MAKEOPTS=

If there no `=' sign then it's filename otherwise it's variable and should be just evaled. 
Comment 9 Anton Starikov 2004-08-31 19:53:19 UTC
Agree. But it will require just a bit more complex parser :) but it can be done.
Comment 10 SpanKY gentoo-dev 2004-10-01 08:34:05 UTC
*** Bug 66020 has been marked as a duplicate of this bug. ***
Comment 11 SpanKY gentoo-dev 2005-01-07 15:51:08 UTC
*** Bug 76684 has been marked as a duplicate of this bug. ***
Comment 12 Carsten Lohrke (RETIRED) gentoo-dev 2005-02-15 18:06:58 UTC
*** Bug 82189 has been marked as a duplicate of this bug. ***
Comment 13 SpanKY gentoo-dev 2005-03-28 21:14:03 UTC
*** Bug 86722 has been marked as a duplicate of this bug. ***
Comment 14 Sven Wegener gentoo-dev 2005-04-07 22:37:56 UTC
*** Bug 88311 has been marked as a duplicate of this bug. ***
Comment 15 Jason Stubbs (RETIRED) gentoo-dev 2005-04-21 00:33:15 UTC
*** Bug 89890 has been marked as a duplicate of this bug. ***
Comment 16 Jason Stubbs (RETIRED) gentoo-dev 2005-05-16 16:35:05 UTC
*** Bug 51023 has been marked as a duplicate of this bug. ***
Comment 17 Stephen Bennett (RETIRED) gentoo-dev 2005-07-02 11:57:41 UTC
*** Bug 97750 has been marked as a duplicate of this bug. ***
Comment 18 Jason Stubbs (RETIRED) gentoo-dev 2005-07-28 07:26:09 UTC
Putting a hold on feature requests for portage as they are drowning out the 
bugs. Most of these features should be available in the next major version of 
portage. But for the time being, they are just drowning out the major bugs and 
delaying the next version's progress. 
 
Any bugs that contain patches and any bugs for etc-update or dispatch-conf can 
be reopened. Sorry, I'm just not good enough with bugzilla. ;) 
Comment 19 Wojciech Potentas 2005-08-03 21:52:20 UTC
 I'm installing gentoo on my friends P4 host, and had many segfault compilation
 problems. It became obvios that it was an effect of old gcc-3.3.5 compile
marked as default in the profile (2005.0) I don't know how such old thing was
found on the system but it generated many of errors. I think you'll could mark
some bugs as 
duplication of something like this.
Comment 20 Mark Purtill 2005-10-31 20:19:20 UTC
It looks like with a little effort, per-package environment variables are
possible now.  See the message
<http://article.gmane.org/gmane.linux.gentoo.user/143322> (not by me, but I
tried the method suggested and it appears to work).
Comment 21 Harald van Dijk (RETIRED) gentoo-dev 2005-11-03 02:17:11 UTC
*** Bug 111328 has been marked as a duplicate of this bug. ***
Comment 22 Nguyen Thai Ngoc Duy (RETIRED) gentoo-dev 2005-11-03 06:35:15 UTC
I have a patch that works in my case (LINGUAS of openoffice-bin). It uses
/etc/portage/package.env. The format is as follow:
package-spec filename
where filename is /etc/portage/env/filename (same format as /etc/env.d/*).
In my case that would be
app-office/openoffice-bin linguas
And /etc/portage/env/linguas is:
LINGUAS="en vi"

You should know that i'm not a portage developer. This patch is not perfect (i
still don't know how config.reset/.modifying works). Hope that this can be used
as a base for other experiments (for example, when filename and direct env
assignment is used as in comment #8). Hope portage devs look at it and fix this
patch though :)
Comment 23 Nguyen Thai Ngoc Duy (RETIRED) gentoo-dev 2005-11-03 06:36:13 UTC
Created attachment 72015 [details, diff]
portage.py patch against portage-2.0.53_rc7
Comment 24 Nguyen Thai Ngoc Duy (RETIRED) gentoo-dev 2005-11-03 06:41:32 UTC
Forgot to mention that this patch only accept new environment variables.
Variables that are already set by portage or something else will not be
overridden, so don't try to override PV, PF or something else. A better approach
would be the ebuild it self will specify which variable can be overridden. Then
portage may notify users which variable can be used in package.env
Comment 25 Jason Stubbs (RETIRED) gentoo-dev 2005-11-03 07:17:45 UTC
Created attachment 72017 [details, diff]
Integrated setenv into setcpv

I like the idea of using a separate file.

I made the following changes:
* Dropped setenv and moved the code into setcpv
* Dropped the setting of ENV
* Make changes in the "pkg" subconfig rather than the aggregated config
* Allow specifying multiple env files
* Added support for incrementals across the env files
Comment 26 Nguyen Thai Ngoc Duy (RETIRED) gentoo-dev 2005-11-03 07:55:13 UTC
WORKSFORME  (LINGUAS/openoffice-bin) :)
Anyone willing to test Jason's patch on other ebuilds?
Comment 27 Jakub Moc (RETIRED) gentoo-dev 2005-11-04 03:34:57 UTC
*** Bug 111458 has been marked as a duplicate of this bug. ***
Comment 28 Jason Stubbs (RETIRED) gentoo-dev 2005-12-01 04:29:52 UTC
*** Bug 51061 has been marked as a duplicate of this bug. ***
Comment 29 Jakub Moc (RETIRED) gentoo-dev 2006-01-21 08:54:50 UTC
*** Bug 119830 has been marked as a duplicate of this bug. ***
Comment 30 tim 2006-01-21 10:56:37 UTC
the recent patch works for several ebuilds on my system ... i'd propose to add it to portage, soon ...
Comment 31 SpanKY gentoo-dev 2006-01-24 17:01:26 UTC
got a good patch it looks like
Comment 32 Matteo Sasso 2006-06-29 13:07:57 UTC
Created attachment 90464 [details, diff]
New patch for portage v2.1-r1

I found this patch useful to work around packages that don't support the --as-needed linker flag yet. I also like to compile most packages with -Os but I prefer -O2 for more computational intensive programs (e.g. gcc).
This is a small update which applies cleanly against portage-2.1-r1.
I see there wasn't much activity in this thread lately but I really hope to see this included in portage! ;)
Comment 33 Matteo Sasso 2006-06-29 13:12:38 UTC
Ah, by the way: this is my first patch ever. I made it with diff -ut. Please tell me if it doesn't work for some reason (probably my fault) or if you think I should have used different flags.

Thank you.
Comment 34 Zac Medico gentoo-dev 2006-06-29 13:34:50 UTC
I'm not sure that it's a good idea to include support for something like this in the portage.config class.  The approach suggested in comment #20  is a per-package bashrc implementation, which works well and is very flexible.  There has been talk of including something like this in the base profile here:

http://article.gmane.org/gmane.linux.gentoo.devel/38920
Comment 35 Matteo Sasso 2006-06-29 14:41:14 UTC
Wow, I didn't know there was a discussion at Gmane... Sorry, I didn't read older posts.
Anyway, I really don't know enough about the internal workings of portage. I'll just leave this decision to the devs, since it probably has some deeper implications.

Thanks for the pointer, Zac! :)
Comment 36 solar (RETIRED) gentoo-dev 2006-06-29 15:09:47 UTC
A slightly modified version of the code from the thread has been commited to the 
tree. It addresses all the desires that were raised and works with the new 
portage-2.1.
Comment 37 Carsten Lohrke (RETIRED) gentoo-dev 2006-07-04 08:43:38 UTC
*** Bug 139182 has been marked as a duplicate of this bug. ***
Comment 38 Sascha Silbe 2006-07-20 05:19:11 UTC
What's the current state of this? I wanted to change LINGUAS for man-pages, but none of the proposed config files works and /etc/profile/bashrc isn't opened during "emerge -pv man-pages".

Comment 39 Nguyen Thai Ngoc Duy (RETIRED) gentoo-dev 2006-07-21 02:41:58 UTC
Is it possible to list customized env variables in emerge -pv?
Comment 40 Jakub Moc (RETIRED) gentoo-dev 2006-07-25 05:56:17 UTC
*** Bug 141698 has been marked as a duplicate of this bug. ***
Comment 41 Harald van Dijk (RETIRED) gentoo-dev 2006-08-05 08:56:39 UTC
> What's the current state of this? I wanted to change LINGUAS for man-pages, but
> none of the proposed config files works and /etc/profile/bashrc isn't opened
> during "emerge -pv man-pages".

It requires a portage patch. The patch from comment #32 -- after minor updates because of portage changes -- works. Any bashrc implementation, including the current one, will be executed too late to affect dependencies and would have no effect on man-pages, and even causes build failures for things like firefox.

mkdir -p /etc/portage/env/www-client
echo LINGUAS=de >/etc/portage/env/www-client/mozilla-firefox
echo LINGUAS=en_GB >>/etc/make.conf
emerge www-client/mozilla-firefox

Watch as portage fetches the en_GB xpi file, tries to unpack the de xpi file, and aborts the installation.
Comment 42 Zac Medico gentoo-dev 2006-08-05 11:57:36 UTC
(In reply to comment #39)
> Is it possible to list customized env variables in emerge -pv?

That would be possible to implement if we include package.env support.

(In reply to comment #41)
> echo LINGUAS=de >/etc/portage/env/www-client/mozilla-firefox
> echo LINGUAS=en_GB >>/etc/make.conf

An alternative approach is to put the USE_EXPAND flags into package.use:

echo www-client/mozilla-firefox linguas_de >> /etc/portage/package.use

Comment 43 Harald van Dijk (RETIRED) gentoo-dev 2006-08-05 12:08:32 UTC
> (In reply to comment #41)
> > echo LINGUAS=de >/etc/portage/env/www-client/mozilla-firefox
> > echo LINGUAS=en_GB >>/etc/make.conf
> 
> An alternative approach is to put the USE_EXPAND flags into package.use:
> 
> echo www-client/mozilla-firefox linguas_de >> /etc/portage/package.use

ITYM:
echo www-client/mozilla-firefox linguas_de -linguas_en_GB >> /etc/portage/package.use

That's not an alternative approach, that's an additional approach. mozilla-firefox uses the LINGUAS variable directly, so only changing USE isn't enough. Also, it's a huge hack. (It's a good hack until a fix is available, so thanks, but it's still a hack. :) )
Comment 44 Zac Medico gentoo-dev 2006-08-05 12:16:49 UTC
(In reply to comment #43)
> That's not an alternative approach, that's an additional approach.
> mozilla-firefox uses the LINGUAS variable directly, so only changing USE isn't
> enough. Also, it's a huge hack. (It's a good hack until a fix is available, so
> thanks, but it's still a hack. :) )

Ebuilds really shouldn't use USE_EXPAND variables directly.  They should check the $USE variable for the corresponding linguas_* flags.

Comment 45 Harald van Dijk (RETIRED) gentoo-dev 2006-08-05 12:26:07 UTC
> (In reply to comment #43)
> > That's not an alternative approach, that's an additional approach.
> > mozilla-firefox uses the LINGUAS variable directly, so only changing USE isn't
> > enough. Also, it's a huge hack. (It's a good hack until a fix is available, so
> > thanks, but it's still a hack. :) )
> 
> Ebuilds really shouldn't use USE_EXPAND variables directly.  They should check
> the $USE variable for the corresponding linguas_* flags.

That's not an option. firefox also needs to find the first supported LINGUAS entry, and the order is not preserved in USE.
Comment 46 Zac Medico gentoo-dev 2006-08-05 13:56:54 UTC
The interaction between USE and USE_EXPAND variables leads to a circular situation where environment variables translate to USE flags and vice versa.  It's really quite messy.  It seems like we should cleanse USE_EXPAND variables from the ebuild environment in order to prevent them from being used for any thing other than the generation of USE flags.
Comment 47 Harald van Dijk (RETIRED) gentoo-dev 2006-08-05 14:03:34 UTC
(In reply to comment #46)
> The interaction between USE and USE_EXPAND variables leads to a circular
> situation where environment variables translate to USE flags and vice versa. 
> It's really quite messy.

In my opinion, USE should not change USE_EXPAND variables at all. LINGUAS="xxx" should add linguas_xxx to USE, but adding linguas_xxx to USE doesn't need to be supported.

> It seems like we should cleanse USE_EXPAND variables
> from the ebuild environment in order to prevent them from being used for any
> thing other than the generation of USE flags.

LINGUAS was a gettext invention, and you're suggesting forbidding gettext-based build systems from using it?
Comment 48 Zac Medico gentoo-dev 2006-08-05 14:08:56 UTC
(In reply to comment #47)
> LINGUAS was a gettext invention, and you're suggesting forbidding gettext-based
> build systems from using it?

In cases like that, it not really an option.  Anyway, there's a mess that needs to be sorted out here, and I'll think about it some more.
Comment 49 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2006-08-08 15:35:31 UTC
*** Bug 143264 has been marked as a duplicate of this bug. ***
Comment 50 Harald van Dijk (RETIRED) gentoo-dev 2006-08-20 10:17:59 UTC
Created attachment 94711 [details, diff]
Updated patch for 2.1.1_pre5-r2
Comment 51 Wojciech Potentas 2006-09-26 10:38:35 UTC
 I think there is a bug when you have something in USE flags, for ex. "alsa", and you want to build package without alsa disabling it in /etc/portage/package.use "-alsa". I experienced problems doing this case package is still build with alsa compiled in.
Comment 52 Simon Stelling (RETIRED) gentoo-dev 2006-09-26 10:42:33 UTC
(In reply to comment #51)
>  I think there is a bug when you have something in USE flags, for ex. "alsa",
> and you want to build package without alsa disabling it in
> /etc/portage/package.use "-alsa". I experienced problems doing this case
> package is still build with alsa compiled in.

This is not relevant to per-package env. Most likely the problem is that you have two p.use entries for the same package, and portage only picks up the first/last of them.
Comment 53 Wojciech Potentas 2006-09-27 01:59:07 UTC
 Yes, one in USE flags in make.conf, and second in /etc/portage/packages.use.

I thought we can speak about it here, case /etc/portage/package.use are per package enviroment vairables.If not, I'll open another bug, but I can't find good title for it.
Comment 54 Jakub Moc (RETIRED) gentoo-dev 2006-10-05 04:46:59 UTC
*** Bug 150158 has been marked as a duplicate of this bug. ***
Comment 55 Jakub Moc (RETIRED) gentoo-dev 2006-11-21 00:18:38 UTC
*** Bug 155821 has been marked as a duplicate of this bug. ***
Comment 56 Marius Mauch (RETIRED) gentoo-dev 2007-01-12 06:23:58 UTC
*** Bug 105199 has been marked as a duplicate of this bug. ***
Comment 57 Jakub Moc (RETIRED) gentoo-dev 2007-06-03 15:46:32 UTC
*** Bug 180748 has been marked as a duplicate of this bug. ***
Comment 58 Zac Medico gentoo-dev 2007-09-17 02:33:51 UTC
*** Bug 192699 has been marked as a duplicate of this bug. ***
Comment 59 Robin Bankhead 2007-09-17 19:31:25 UTC
As my bug (Bug 192699) has been duped into this one, I'd like to outline the case I made in that bug. It relates to dev-java/java-sdk-docs but I'd surmise that other documentation packages might also be affected.

With FEATURES="nodoc", java-sdk-docs goes through the whole emerge process (basically unzipping >300MB of HTML), copies it into the install image at /usr/share/doc/, and then when nodoc is invoked, erases the whole lot.

This was somewhat frustrating on my low-resource laptop, where the whole fruitless exercise cost ~25 minutes on niceness=5. Depending where you stand, either the ebuild maintainer should have been more mindful of portage's architecture, or portage should have a rethink on the relationship between docs packages and a feature like nodoc.

I hope this is not characterised as a corner case, the essence of this thread seems more concerned with compiler flags and user-accessible granularity, where personally I feel providing more granularity (or ability to override certain things) for ebuild maintainers would be the really useful thing to avoid logic-bombs like I experienced.
Comment 60 Ryan Hill (RETIRED) gentoo-dev 2008-12-06 06:32:08 UTC
I am very much in need of per-package FEATURES in order to disable tests for specific packages/versions.  I do pretty much continuous tree rebuilds with unreleased GCC versions for gcc-porting.  This highly depends on package testsuites to catch wrong-code bugs (eg. with 4.4 over half the bugs I've found so far have been caught by testsuites and not the compiler).

Unfortunately, there are a very large number of packages in the tree that have broken testsuites.  This means that my runs are constantly interrupted by failures that are just noise, making it impossible to automate.  If I do use --keep-going, I get a crapload of false positives - each and every one of which I have to investigate to see if the failure is caused by GCC or is just generally broken.  Also (though I'm not sure of this, I've never explicitly checked - please correct me if I'm wrong) failed ebuilds will cause their dependents to be removed from the depgraph, meaning many packages won't get rebuilt.

currently i use a nasty hack in /etc/portage/env/cat/pkg:

dirtyepic@halo ~ $ cat /etc/portage/env/dev-util/dejagnu
FEATURES=" ${FEATURES}"
FEATURES=${FEATURES/ test/}

Besides being a nasty hack this won't disable the test USE flag, meaning extra dependencies are pulled in (not usually a problem, but sometimes) and code conditional on USE=test gets run, which does on occasional break things when src_test has been skipped.

A package.features (or even package.test) would be greatly appreciated.
Comment 61 Zac Medico gentoo-dev 2008-12-06 06:53:59 UTC
I am planning to merge package.env support (or something similar) soon.

(In reply to comment #60)
> I am very much in need of per-package FEATURES in order to disable tests for
> specific packages/versions.

You can already disable tests on a per-package basis by masking the "test" flag in package.use.mask. To do it locally, put your masks in /etc/portage/profile/package.use.mask.
Comment 62 Ryan Hill (RETIRED) gentoo-dev 2008-12-06 07:11:34 UTC
awesome, i didn't think of that. thanks :)
Comment 63 Martin 2009-07-01 20:56:14 UTC
I'm wondered if package.env is merged. I'm just needing custom cflags per package. Im in masked portage 2.2 and there is nothing about package.env in manpage.
Comment 64 Zac Medico gentoo-dev 2009-07-20 19:09:56 UTC
(In reply to comment #50)
> Created an attachment (id=94711) [edit]
> Updated patch for 2.1.1_pre5-r2

This patch looks pretty good. However, we probably shouldn't use /etc/portage/env/ since that's already used by profiles/base/profile.bashrc and so full bash support is expected there.
Comment 65 Harald van Dijk (RETIRED) gentoo-dev 2009-07-20 19:35:55 UTC
I think /etc/portage/env/ is the most logical location, and it was picked long before profiles/base/profile.bashrc existed and won't conflict with the profile use anyway: profile.bashrc reads subdirectories, this patch normally reads only /etc/portage/env/*. I don't think it will be a problem to have both read /etc/portage/env. You could make sure package.env contains no directory separators, and then even the possibility won't exist. (If you've got a better location go for it; I just haven't got a better location. :))
Comment 66 Peter Volkov (RETIRED) gentoo-dev 2009-09-27 08:54:06 UTC
Another use case for per-package FEATURES is to disable distcc for some packages. E.g. for glibc it's known to break with distcc (bug 276301) so to avoid manual work I'd like to disable it for glibc only.
Comment 67 Thomas Scheiblauer 2010-01-10 19:58:25 UTC
you could utilize the portage-bashrc.tar.gz from this site:
http://www.mathematik.uni-wuerzburg.de/~vaeth/gentoo/index.html

I'v been using it successfully for years.
Comment 68 Peter Volkov (RETIRED) gentoo-dev 2010-01-11 07:26:42 UTC
(In reply to comment #67)
> you could utilize the portage-bashrc.tar.gz from this site:
> http://www.mathematik.uni-wuerzburg.de/~vaeth/gentoo/index.html

Tomas that bashrc is not required any more since $PORTDIR/profile/base/profile.bashrc already allows to specify env for packages without any additional bashrc scripts. The problem that's left unresolved here is per-package FEATURES (useful e.g. for kernel packages to avoid binpkg).
Comment 69 Thomas Scheiblauer 2010-01-11 07:43:59 UTC
@Peter: this script also supports the FEATURES variable, e.g. I use it like this in '/etc/portage/package.cflags/local':

dev-util/cmake FEATURES-="distcc" MAKEOPTS="-j4"
sys-libs/glibc FEATURES-="distcc" MAKEOPTS="-j4"
media-sound/jack-audio-connection-kit FEATURES-="ccache distcc" MAKEOPTS="-j1"
media-video/ffmpeg -ftree-vectorize
...

the '-=' removes the specified features.
Comment 70 Peter Volkov (RETIRED) gentoo-dev 2010-01-11 13:44:13 UTC
> @Peter: this script also supports the FEATURES variable

It states that but if you read comments there:

# sci-libs/blas-atlas FEATURES-=ccache
#  # (certain FEATURES must be set earlier than in this script, but
#  #  certain FEATURES like ccache or nodoc will take effect)

On a quick glance script does the same as base/profile.bashrc and thus it will not work e.g. with buildpkg in FEATURES. Also I guess ccache and nodoc could be disabled with base/profile.bashrc too (by defining FEATURES=${FEATURES/ccache} in /etc/portage/env/category/pkg) but I never tried this. And lastly script is rather long, has some strange special conditions and thus may incorporate new points of failures so IMHO it's better to prefer in-stock bashrc. That said, script prints active variables and thus could be useful for that and I'm not going to engage anybody not to use whatever they prefer ;)
Comment 71 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2010-04-22 17:52:04 UTC
Created attachment 228783 [details, diff]
Per-package bashrc support

I've created a patch adding support for per-package bashrc files in /etc/portage/env. Well, that's nothing really new but only moving to Portage stuff which should have been implemented there.
Comment 72 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2010-04-22 17:53:41 UTC
Created attachment 228785 [details, diff]
Helper patch to profile.bashrc

After applying the above patch to Portage, the system-wide profile.bashrc should be modified like that to avoid double sourcing.
Comment 73 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2010-04-23 22:06:43 UTC
Created attachment 228929 [details, diff]
Per-package bashrc support (with missing unset added)
Comment 74 Zac Medico gentoo-dev 2010-05-07 18:04:02 UTC
(In reply to comment #72)
> Created an attachment (id=228785) [details]
> Helper patch to profile.bashrc

This is in cvs.

(In reply to comment #73)
> Created an attachment (id=228929) [details]
> Per-package bashrc support (with missing unset added)

This is in git.

Comment 75 Zac Medico gentoo-dev 2010-08-21 00:19:27 UTC
(In reply to comment #50)
> Created an attachment (id=94711) [details]
> Updated patch for 2.1.1_pre5-r2

There's a version of this patch in git now:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=5959cb1b25d1d0d7c87fd982df72dfd2212f80a3
Comment 76 Zac Medico gentoo-dev 2010-08-23 06:20:18 UTC
This is in 2.2_rc68, but I'll leave this bug open until it's in an unmasked version.
Comment 77 Harald van Dijk (RETIRED) gentoo-dev 2010-08-23 23:03:19 UTC
The current support seems to have problems. I have FEATURES=test set in make.conf. Now, when I do

# FEATURES=-test emerge iasl

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] sys-power/iasl-20100528  USE="-test*" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB


>>> Verifying ebuild manifests

>>> Emerging (1 of 1) sys-power/iasl-20100528
 * acpica-unix-20100528.tar.gz RMD160 SHA1 SHA256 size ;-) ...                                                                                                                                              [ ok ]
 * checking ebuild checksums ;-) ...                                                                                                                                                                        [ ok ]
 * checking auxfile checksums ;-) ...                                                                                                                                                                       [ ok ]
 * checking miscfile checksums ;-) ...                                                                                                                                                                      [ ok ]
 * CPV:  sys-power/iasl-20100528
 * REPO: gentoo
 * USE:  amd64 elibc_glibc kernel_linux multilib test userland_GNU
 * You have selected USE="test". This will install the test results
 * into /usr/share/iasl-20100528/, compressed as a tarball.
 * The tests themselves will only rarely die, but the test results
 * are interesting for arch testing. The tests may take quite some
 * time to complete.
>>> Unpacking source...

emerge first says it's going to build iasl with USE=-test, but USE=test gets enabled during the actual build anyway.
Comment 78 Zac Medico gentoo-dev 2010-08-24 01:43:23 UTC
(In reply to comment #77)
> The current support seems to have problems.

I didn't reproduce that. Hopefully this solves it though:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=438db16d8afef9ad00b2792e529b889e13f2e9b3
Comment 79 Harald van Dijk (RETIRED) gentoo-dev 2010-08-24 05:39:30 UTC
(In reply to comment #78)
> I didn't reproduce that. Hopefully this solves it though:

It doesn't, but when I try the same thing on a different system, there is no problem for me either. I'll try to figure out what the relevant difference between the two systems is.
Comment 80 Harald van Dijk (RETIRED) gentoo-dev 2010-08-24 16:20:17 UTC
If I build flex, bison, and iasl with FEATURES=test (from make.conf), then try to rebuild iasl with FEATURES=-test (from the environment), test stays enabled, on both systems. There are no package.env entries for any of these.
Comment 81 Zac Medico gentoo-dev 2010-08-24 16:55:06 UTC
(In reply to comment #80)
> If I build flex, bison, and iasl with FEATURES=test (from make.conf), then try
> to rebuild iasl with FEATURES=-test (from the environment), test stays enabled,
> on both systems. There are no package.env entries for any of these.

I can't reproduce that. Do you get the same results if you try the same operation with the ebuild(1) command instead of emerge? If you temporarily disable FEATURES=test in make.conf does it correctly disable the tests? Do you have anything in bashrc that might be interfering with USE? 
Comment 82 Harald van Dijk (RETIRED) gentoo-dev 2010-08-24 17:15:40 UTC
(In reply to comment #81)
> I can't reproduce that. Do you get the same results if you try the same
> operation with the ebuild(1) command instead of emerge?

No, the tests get disabled properly then.

> If you temporarily
> disable FEATURES=test in make.conf does it correctly disable the tests?

Yes, that also properly disables the tests.

> Do you
> have anything in bashrc that might be interfering with USE? 

I see this same problem when I move my entire /etc/portage/bashrc somewhere else.

I also see this with emerge --nodeps (and FEATURES=test in make.conf, FEATURES=-test in the environment), so the fact that it triggered on my other system after installing flex and bison with FEATURES=test must be unrelated, and it might only be the installation of iasl itself with FEATURES=test that matters... except when rebuilding it with FEATURES=-test, then enabling FEATURES=test again, the problem persists.
Comment 83 Zac Medico gentoo-dev 2010-08-24 17:19:37 UTC
(In reply to comment #82)
File a new bug please.
Comment 84 Harald van Dijk (RETIRED) gentoo-dev 2010-08-24 17:25:07 UTC
(In reply to comment #83)

Done, #334319.
Comment 85 Zac Medico gentoo-dev 2010-09-04 07:55:15 UTC
This is fixed in 2.1.9.
Comment 86 onip 2010-09-06 14:52:51 UTC
# cat /etc/portage/package.env
x11-drivers/nvidia-drivers NoBinPackage

# cat /etc/portage/env/NoBinPackage 
FEATURES="fixpackages fixlafiles sandbox parallel-fetch -buildpkg -metadata-transfer"

If I do an emerge -DuNav world (or directly emerge it )the binpackage is built anyway.

What am I missing here?
Comment 87 onip 2010-09-06 14:54:06 UTC
forgot to say that I am on 2.1.9
Comment 88 Zac Medico gentoo-dev 2010-09-06 16:25:35 UTC
(In reply to comment #86)
> # cat /etc/portage/env/NoBinPackage 
> FEATURES="fixpackages fixlafiles sandbox parallel-fetch -buildpkg
> -metadata-transfer"
> 
> If I do an emerge -DuNav world (or directly emerge it )the binpackage is built
> anyway.
> 
> What am I missing here?

There are some FEATURES settings that currently do not work for package.env, and in this case the settings from make.conf are used. This is the case with FEATURES=buildpkg. Please file separate bugs for any issues like this that you notice.
Comment 89 Zac Medico gentoo-dev 2011-09-03 06:30:29 UTC
*** Bug 320457 has been marked as a duplicate of this bug. ***