adding list of variables exported by make.conf to emerge --info
 

People frequently break their systems by exporting weird variables like
SYSTEM from /etc/make.conf (USE variable "grouping").

Example here: <http://forums.gentoo.org/viewtopic.php?p=6915550#6915550>

What do you think about adding list of variables in make.conf to emerge
--info ? I know we can always ask for the make.conf, but it either
requires asking for a large amount of info up front, or increases the
number of round-trips (emerge --info looks normal, ask for make.conf).

adding list of variables exported by make.conf to emerge --info
 

El lun, 16-01-2012 a las 11:54 +0100, "Paweł Hajdan, Jr." escribió:
> People frequently break their systems by exporting weird variables like
> SYSTEM from /etc/make.conf (USE variable "grouping").
>
> Example here: <http://forums.gentoo.org/viewtopic.php?p=6915550#6915550>
>
> What do you think about adding list of variables in make.conf to emerge
> --info ? I know we can always ask for the make.conf, but it either
> requires asking for a large amount of info up front, or increases the
> number of round-trips (emerge --info looks normal, ask for make.conf).
>

I agree but, why not *also* make portage warn people when they are
exporting some "known to break" variables in their make.conf?

adding list of variables exported by make.conf to emerge --info
 

On 01/16/2012 02:54 AM, "Paweł Hajdan, Jr." wrote:
> People frequently break their systems by exporting weird variables like
> SYSTEM from /etc/make.conf (USE variable "grouping").
>
> Example here: <http://forums.gentoo.org/viewtopic.php?p=6915550#6915550>
>
> What do you think about adding list of variables in make.conf to emerge
> --info ? I know we can always ask for the make.conf, but it either
> requires asking for a large amount of info up front, or increases the
> number of round-trips (emerge --info looks normal, ask for make.conf).

Sensitive variables fall into at least 2 categories:

(1) Variables that the user may have a valid reason to set, though
the value needs to be valid if it is set. An example might be the
COLUMNS variable, which can trigger bug 394091 [1].

(2) Variables which may case a build to fail and there is no valid
reason for the user to set them in the context of a particular
ebuild. An example might be the SYSTEM variables, which can trigger
bug 372519 [2].

For case (2) it makes sense for ebuilds to explicitly unset or export -n
the relevant variables, since those variables only serve to allow the
users to hurt themselves.

[1] https://bugs.gentoo.org/show_bug.cgi?id=394091
[2] https://bugs.gentoo.org/show_bug.cgi?id=372519
--
Thanks,
Zac

adding list of variables exported by make.conf to emerge --info
 

On 1/16/12 12:36 PM, Pacho Ramos wrote:
> I agree but, why not *also* make portage warn people when they are
> exporting some "known to break" variables in their make.conf?

That'd require coming up with such list of "known bad" variable names,
and generally I don't think blacklisting is very effective.

It's relatively easy to invent a breaking name, but hard to enumerate
them all.

Anyway, that's a superset of my original proposal, so I'm fine if
someone wants to experiment with it.

adding list of variables exported by make.conf to emerge --info
 

On 01/16/2012 02:54 AM, "Paweł Hajdan, Jr." wrote:
> People frequently break their systems by exporting weird variables like
> SYSTEM from /etc/make.conf (USE variable "grouping").
>
> Example here: <http://forums.gentoo.org/viewtopic.php?p=6915550#6915550>
>
> What do you think about adding list of variables in make.conf to emerge
> --info ? I know we can always ask for the make.conf, but it either
> requires asking for a large amount of info up front, or increases the
> number of round-trips (emerge --info looks normal, ask for make.conf).

I think what want already exists:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/info_vars

Am I right?

--
Thanks,
Zac

adding list of variables exported by make.conf to emerge --info
 

On 1/17/12 6:35 PM, Zac Medico wrote:
> On 01/16/2012 02:54 AM, "Paweł Hajdan, Jr." wrote:
>> People frequently break their systems by exporting weird variables like
>> SYSTEM from /etc/make.conf (USE variable "grouping").
>>
>> Example here: <http://forums.gentoo.org/viewtopic.php?p=6915550#6915550>
>>
>> What do you think about adding list of variables in make.conf to emerge
>> --info ? I know we can always ask for the make.conf, but it either
>> requires asking for a large amount of info up front, or increases the
>> number of round-trips (emerge --info looks normal, ask for make.conf).
>
> I think what want already exists:
>
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/info_vars
>
> Am I right?

Not really. Even the example SYSTEM is not listed there, and as said
before we can't put every possible, now and in the future, bad variable
name there.

I think another line should be added to emerge --info, like this (just
an example, most variables omitted):

Variables defined in make.conf: CFLAGS, CXXFLAGS, SYSTEM, ...

adding list of variables exported by make.conf to emerge --info
 

On Tue, 17 Jan 2012 18:41:47 +0100
""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:

> Not really. Even the example SYSTEM is not listed there, and as said
> before we can't put every possible, now and in the future, bad
> variable name there.

Wouldn't the environment file reveal these bad variables? emerge output
has suggested attaching that to any bug reports for a long time, even
though usually it isn't necessary.


jer

adding list of variables exported by make.conf to emerge --info
 

El mar, 17-01-2012 a las 18:23 +0100, "Paweł Hajdan, Jr." escribió:
> On 1/16/12 12:36 PM, Pacho Ramos wrote:
> > I agree but, why not *also* make portage warn people when they are
> > exporting some "known to break" variables in their make.conf?
>
> That'd require coming up with such list of "known bad" variable names,
> and generally I don't think blacklisting is very effective.
>
> It's relatively easy to invent a breaking name, but hard to enumerate
> them all.
>
> Anyway, that's a superset of my original proposal, so I'm fine if
> someone wants to experiment with it.
>

The idea would be to fill that list when we get a bug report with user
having problems due a variable and, then, prevent it from occurring in
the future. This is similar to add "unset BLABLABLA" to our ebuilds when
we get a bug report but with the advantage of covering more possible
packages that could fail if the same variable is set.

adding list of variables exported by make.conf to emerge --info
 

"Paweł Hajdan, Jr." wrote:

On 1/17/12 6:35 PM, Zac Medico wrote:

I think what want already exists:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/info_vars

Am I right?


Not really. Even the example SYSTEM is not listed there, and as said
before we can't put every possible, now and in the future, bad variable
name there.

I think another line should be added to emerge --info, like this (just
an example, most variables omitted):

Variables defined in make.conf: CFLAGS, CXXFLAGS, SYSTEM, ...



It seems that emerge --info --verbose does that (at least with portage-2.2)

I'm used to define USE_*¹ variables in my make.conf in order to split
out global USEs. Those variables does not appear in the emerge --info
output, but they are visible if I had --verbose.


--
Cyprien
Fulax on #gentoo-lisp

1. This naming scheme isn't safe either, as USE_EXPAND and USE_ORDER are
make.conf settings