1 |
On Wed, Jan 6, 2021 at 11:05 AM Patrick McLean <chutzpah@g.o> wrote: |
2 |
> |
3 |
> On Wed, 6 Jan 2021 15:02:12 +0100 |
4 |
> Thomas Deutschmann <whissi@g.o> wrote: |
5 |
> |
6 |
> > Hi, |
7 |
> > |
8 |
> > is there a specific reason why we want to support dynamic variables |
9 |
> > (ACCT_USER_$foo) at all? |
10 |
> > |
11 |
> > Isn't package.env support enough, i.e. use ACCT_USER_ID from environment |
12 |
> > if set (which we should detect and log, maybe this will require a |
13 |
> > different namespace for the variables at all to be able to differentiate |
14 |
> > between values set by acct-* ebuild and user override)? |
15 |
> > |
16 |
> > Of course this won't allow something like `ACCT_USER_ID=42 emerge |
17 |
> > <package which will pull in multiple acct-user/*>` but I am not sure if |
18 |
> > this is an implementation goal. |
19 |
> |
20 |
> This is so ACCT_USER_$foo can be set in make.conf, and not have to |
21 |
> be specified as an environment variable whenever portage is run. This |
22 |
> helps when automated systems are building Gentoo images or systems. |
23 |
> |
24 |
|
25 |
Not sure I follow. Whether your automation sets a variable in |
26 |
/etc/portage/make.conf or /etc/portage/package.env; it's basically the |
27 |
same problem space; no? |
28 |
|
29 |
-A |