Re: [gentoo-portage-dev] [Bug 44796] Per package environment variables

[Thomas de Grenier de Latour]

On Fri, 4 Nov 2005 01:19:35 +0900
Jason Stubbs <jstubbs@g.o> wrote:

> package.env would be a list of "<atom> <file> [<file> ...]"
...
> With a couple of small modifications to emerge to check FEATURES
> for "buildpkg" after the call to setcpv() is done rather than
> doing it once globally, this would also cover TGL's BUILD_PKGS
> addition too.

Not if env files are only selectable by strict depatoms. I mean,
sure this syntax is perfect for *DEPEND strings, and is fine for
package.{use,mask,unmask} (although the randomness of
best_match_to_list() is rather annoying). But for package.keywords,
it is already sub-optimal imho (i run ~arch so i don't care
much, but for instance i often see people on forums who list
some whole categories there), and it would be too for the generic
package.env.  For instance, people who develop gnome stuffs might
want to use the debug env for gnome-*/* packages.  As for
the buildpkg FEATURES flag, it would be a real pita if i had to list
all packages matched by my current BUILD_PKGS spec (just look at
the examples i've put in my email on that topic to get the idea).

Since being able to list several env file on a same line doesn't
sounds like a must have feature to me, i would much prefer a
package.env format of that kind:
  <rule> [<rule> ...]    <envfile>
where <rule> would be similar to what i've defined for BUILD_PKGS
(with addition of full versioned dep atoms, which is a trivial
change to my code).  And if a package happens to match the rules
lists of several lines, then the corresponding env files would all
be sourced, in the order of the said lines.  I can try to implement
that if you agree on the idea.


My second concern is about unsupported variables (some of the
FEATURES flags, some of the *DIR locations, etc.): i think they
should be somehow blacklisted, to avoid crazy breakages/bugreports
(btw, a quick look on the variables listed in make.conf.example
made me realize it was not that easy to write an accurate
blacklist, which tends to confirm it's really needed).

-- 
TGL.
-- 
gentoo-portage-dev@g.o mailing list