Re: [gentoo-dev] adding list of variables exported by make.conf to emerge --info

2012-01-17 Thread Paweł Hajdan, Jr.
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.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] adding list of variables exported by make.conf to emerge --info

2012-01-17 Thread Zac Medico
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



Re: [gentoo-dev] adding list of variables exported by make.conf to emerge --info

2012-01-17 Thread Paweł Hajdan, Jr.
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, ...



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] adding list of variables exported by make.conf to emerge --info

2012-01-17 Thread Jeroen Roovers
On Tue, 17 Jan 2012 18:41:47 +0100
Paweł Hajdan, Jr. phajdan...@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



Re: [gentoo-dev] adding list of variables exported by make.conf to emerge --info

2012-01-17 Thread Pacho Ramos
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.


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] adding list of variables exported by make.conf to emerge --info

2012-01-17 Thread Cyprien Nicolas

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




[gentoo-dev] adding list of variables exported by make.conf to emerge --info

2012-01-16 Thread Paweł Hajdan, Jr.
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).



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] adding list of variables exported by make.conf to emerge --info

2012-01-16 Thread Pacho Ramos
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?


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] adding list of variables exported by make.conf to emerge --info

2012-01-16 Thread Zac Medico
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