Zac, Michal, Would you be willing to merge this ? If env/ instead of package.env is a deal breaker, I can change that. A bashrc like mechanism is more practical for us but package.env will do the trick too and we really want to have this in mainline portage.
Thanks, Bertrand On Thu, Sep 18, 2014 at 10:54 AM, Bertrand Simonnet <bsimon...@google.com> wrote: > For my purpose, I think bash scripting would be more useful. I thought > about package.env > in the beginning (see first few messages on this thread) as it would help > us reuse code but > variable setting only will limit what we can do. > > If you want package.env, we can implement it too and have both mechanisms > available. > > Thanks, > Bertrand > > On Thu, Sep 18, 2014 at 1:02 AM, Michał Górny <mgo...@gentoo.org> wrote: > >> Dnia 2014-09-17, o godz. 14:57:10 >> Bertrand Simonnet <bsimon...@google.com> napisał(a): >> >> > I'd rather use the env/ mechanism instead of the package.env one as it >> is >> > more flexible. >> >> It depends on what you aim to do. As portage(5) points out, both have >> their advantages: >> >> - package.env is parsed early, and so allows you override more >> variables, like FEATURES, >> >> - env/ is used as bashrc extension. >> >> The other difference is that package.env supports any atom syntax that >> the particular EAPI supports, while env/ has hardcoded list of >> possibilities. >> >> -- >> Best regards, >> Michał Górny >> > >
