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

[Jason Stubbs]

On Friday 04 November 2005 04:30, Thomas de Grenier de Latour wrote:
> 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).

gnome-*/* for package.keywords is already not supported. There is no 
difference between what I/pclouds is suggesting for package.env and 
package.keywords. What you are really after is for extending the 
configuration syntax to support more than just the DEPEND atom. I was
going to reply to that earlier but this patch came up in between me
reading it and, umm, now.

If the configuration syntax is going to be extended, it needs to be
extended across the board. There is already a (closed) bug asking for
regex atom support. This is essentially what you are asking for with the 
BUILD_PKGS patch. The difference is that you are completely breaking
away from the mostly standard configuration mechanisms portage currently 
supports.

The extension to per-package configuration beyond basic atoms is fine,
but it needs to apply everywhere. If it can remain quick all the better,
but the most important thing is that whatever syntax is used can be used 
whereever an atom can be used at the moment.

> 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.

I don't see the difference in the end result. I can only see a difference in 
perspective. Perhaps you could enlighten me on this point?

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

Rather than blacklist, I'd think that whitelisting is easier. Anything unknown 
to portage (and hence only used on the bash side) will work.

Stuff known to portage that is okay to per-package
--------------------------------------------------
ACCEPT_KEYWORDS
FEATURES="buildpkg ccache distcc keeptemp keepwork noauto noclean nodoc noinfo 
noman nostrip sandbox sfperms suidctl test userpriv usersandbox"
USE

Stuff documented but unknown to portage that will work per-package
------------------------------------------------------------------
MAKE_OPTS
CFLAGS
CHOST
CTARGET
EBEEP_IGNORE
EPAUSE_IGNORE
NOCOLOR

Stuff known to portage but is portage configuration
---------------------------------------------------
FEATURES="autoaddcvs cvs digest distlocks fixpackages getbinpkg gpg mirror 
notitles severe sign strict"
FETCHCOMMAND
GENTOO_MIRRORS
PKGDIR
PORT_LOGDIR
PORTAGE_BINHOST
PORTAGE_NICENESS
PORTAGE_TMPDIR
PORTDIR
PORTDIR_OVERLAY
RESUMECOMMAND
ROOT
RSYNC_EXCLUDEFROM
RSYNC_RETRIES
RSYNC_TIMEOUT
RPMDIR
SYNC
USE_ORDER

* Some of those FEATURES could probably be moved to the supported list

Stuff unknown to portage but is only documented as it affects the default 
FETCH_COMMEND
-------------------------------------------------------------------------
http_proxy
ftp_proxy


The question of facing the supported vs unsupported variables is one that we 
have been facing for some time. Just looking at the short list of those that 
are known to portage and can be supported, it's a hell of a lot of options to 
implement as separate configuration files. Thinking of not support per-
package env in some way or another at some point down the track is pure 
fantasy.

--
Jason Stubbs
-- 
gentoo-portage-dev@g.o mailing list