From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] RFC: Standard build environment variables
Date: Wed, 1 Jul 2020 15:04:50 -0400 [thread overview]
Message-ID: <CAGfcS_k+2CJPJf8Lw1udQPBwdRiAmvswVwgWNq8ArAo5jYSUdA@mail.gmail.com> (raw)
In-Reply-To: <c4648222-ffbb-a029-f029-eda6ecf40933@gentoo.org>
On Wed, Jul 1, 2020 at 9:36 AM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> On 2020-06-30 12:22, Matthew Thode wrote:
> >
> > I'd like to suggest allowing only approved variables in the build
> > environment, having portage unset all variables and setting only what is
> > needed (or configured).
>
> I think this is orthogonal to the problem I'm trying to solve. Even if
> all environment variables had to be whitelisted, ebuilds would still
> need to know how to use them when they happen to be defined.
>
Agree. I'm not actually certain what that proposal was intended to
convey. Are we talking about:
1. Blocking anything that happens to be in the environment when
emerge is run? (Ie 'CFLAGS="-O2" emerge -1 foo'?)
2. Blocking any variable at all that isn't whitelisted by an ebuild
or eclass? (ie CFLAGS in make.conf is ignored unless the ebuild
whitelists it)
I get how environment pollution can cause issues, but #1 is something
we've generally supported for a long time, and it is useful for
troubleshooting/etc or just trying out different things. Maybe a
FEATURE flag could be used to control it to keep newbs out of trouble,
and you can just as easily pass that in the environment too.
I'm not sure that #2 adds a lot of value. The default phase functions
probably already don't work well for exotic build systems, and
eclasses can of course take care of remapping for most of the popular
ones. For one-offs some flag-o-matic or other eclass functions to aid
in remapping variables might be helpful in some cases if there isn't
already something there.
But in any case it isn't essential to what you're proposing. It does
go along with it to a degree and is worth at least thinking about
(imo)...
--
Rich
prev parent reply other threads:[~2020-07-01 19:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-28 12:18 [gentoo-dev] RFC: Standard build environment variables Michael Orlitzky
2020-06-28 14:52 ` Kent Fredric
2020-06-28 15:25 ` Mike Gilbert
2020-06-29 8:44 ` [gentoo-dev] " Agostino Sarubbo
2020-06-29 10:04 ` Ulrich Mueller
2020-06-30 16:22 ` [gentoo-dev] " Matthew Thode
2020-07-01 13:36 ` Michael Orlitzky
2020-07-01 19:04 ` Rich Freeman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGfcS_k+2CJPJf8Lw1udQPBwdRiAmvswVwgWNq8ArAo5jYSUdA@mail.gmail.com \
--to=rich0@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox