Stop implicitly manipulating `NO_COLOR`/`NOCOLOR`

Stop implicitly forcing `NO_COLOR` and `NOCOLOR` in ebuild environment.
This is undesired for several reasons:

1. It makes it impossible to control color for emerge output
   independently of command output, e.g. when one goes to a pty while
   the other goes to logs.

2. It makes it impossible to get color output in logs when running
   `emerge --jobs ...`.

3. Forcing `NO_COLOR=1` turns out to cause random test failures,
   and while fixing them is commendable, it is a pain for arch testing
   and it is currently blocking stabilization requests.

With the new approach, the color output in programs is consistent
between using ``--jobs`` or ``--quiet-build``, and not.  Therefore,
both cases generate uniform logs.  In order to obtain logs free of color
codes, one can either filter them via `ansifilter(1)` (as the manpages
already recommend) or explicitly set `NO_COLOR`.

Furthermore, one can combine color-free build output (for clean logs)
with colorful emerge output by using:

    NO_COLOR=true emerge --color y ...

Bug: https://bugs.gentoo.org/918515
Signed-off-by: Michał Górny <mgorny@gentoo.org>
Closes: https://github.com/gentoo/portage/pull/1188
Signed-off-by: Michał Górny <mgorny@gentoo.org>

1 files changed, 0 insertions, 4 deletions

diff --git a/bin/ebuild b/bin/ebuild
index cbefb5816..69db474c0 100755
--- a/bin/ebuild
+++ b/bin/ebuild
@@ -132,10 +132,6 @@ def main():
         or not sys.stdout.isatty()
     ):
         portage.output.nocolor()
-        portage.settings.unlock()
-        portage.settings["NO_COLOR"] = "true"
-        portage.settings.backup_changes("NO_COLOR")
-        portage.settings.lock()
 
     apply_priorities(portage.settings)