Re: [gentoo-dev] per-package environment variables.

[Olivier Fisette <ribosome@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2370 bytes --]

Hello all,

I see two problems with the implementations that were suggested up to now for 
per-package environment variables.

1) They do not allow any flexibility with regard to package versions, as 
opposed to other Portage configuration files ("package.mask", "package.use", 
etc.). The file "/etc/portage/packages.env/app-shells/bash" would be sourced 
for all versions of "app-shells/bash", for instance. This may be problematic 
for SLOTable packages, and prevents a user from defining or modifying a 
variable for a particular version of a package (to work around a bug, for 
example, such as "pymol-0.95" will segfault when raytracing if compiled with 
"-fgcse").

2) Having a hierarchy of files and directories miroring the Portage tree, with 
symlinks and such, looks a bit complicated more complicated than is needed. 
I'd rather have to deal with only one or a few files.

My initial suggestion was not flexible enough, since it required to declare 
the variables repeatedly for each package. Here is another idea:

A file named "/etc/portage/package.env" could contain entries such as:

app-office/openoffice lang_ru
>=app-sci/emboss-2.8.0 icc
=app-sci/pymol-0.95* gcc_low_opt

The keywords "lang_ru", "ifc" and "gcc_low_opt" would match files with these 
names, contained in "/etc/portage/env.d". These bash scripts would be sourced 
to provide per-package env vars. "/etc/portage/env.d/icc" would contain 
something along these lines:

CC=icc
CXX=icc
CFLAGS="-O2 -xN -noalign"
CXXFLAGS=$CFLAGS
USE="icc"

If we wanted to make things even easier to configure, we could have something 
like the following in "/etc/portage/package.env":

=app-sci/pymol-0.95* [ CC="gcc" CFLAGS="-O1" ]

... were a keyword is replaced by a delimited short bash script that would be 
sourced to provide per package env vars. This would avoid having to create 
files in "/etc/portage/env.d" which target only one package.

I don't think this approach is elegant or powerful. A better mechanism would 
allow to filter and replace flags (like flag-o-matic), to choose compilers 
and have them merged as dependencies when needed, etc. However, per-package 
env vars would be enough in 99 % of the cases, and would extend farther than 
just compilers and compiler flags.

-- 
Olivier Fisette (ribosome)
Gentoo Linux Developer

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]