To get python3 support. #63174 flipped itstool to python3, but itstool
doesn't support python3 until 2.0.3 (and perhaps does not support it
well until 2.0.5).
Pressing forward instead of rolling back at worldofpeace's suggestion,
who mentions that other distros seem to be able to ship recent versions
of itstool.
Tensions in this space seem two-fold. One set centers around libxml2
being a low-level C library with sharp edges, manual memory management,
and performance concerns; the python libxml2 wrapper being quite thin
(the most dubious character in this drama); and python's sentiment that
it ought to be quite hard to crash the interpreter casually. This comes
to a head in https://gitlab.gnome.org/GNOME/libxml2/issues/12 , where a
use-after-free problem in idiomatic-looking python code is declared
working-as-designed.
The other set is around python3 being more UTF-8-aware than libxml2's
python wrapper, such as https://bugzilla.gnome.org/show_bug.cgi?id=789714
and https://src.fedoraproject.org/rpms/libxml2/blob/master/f/libxml2-2.9.8-python3-unicode-errors.patch
itstool is caught in this crossfire merely for being a widely-used
python program that uses XML.
pwndbg is a Python module for gdb. The built-in interpreter is used and
pwndbg offers additional routines. Packaging this is tricky because that
interpreter needs to be used. Using `python3.withPackages` won't work.
By setting `NIX_PYTHONPATH`, the interpreter should pick up pwndbg and
its dependencies.
If `NIX_PYTHONPATH` does not function we can fall back to `PYTHONPATH`.
An example of when that won't work is if pwndbg runs a script of itself
in a subshell. `NIX_PYTHONPATH` would be unset, but `PYTHONPATH` not.
There is a bug in this feature: It allows extra arguments to leak in
from the environment. For example:
$ export extraFlagsArray=date
$ man ls
Note that you get the man page for date rather than for ls. This happens
because 'man' happens to use a wrapper (to add groff to its PATH).
An attempt to fix this was made in 5ae18574fc in PR #19328 for
issue #2537, but 1. That change didn't actually fix the problem because
it addressed makeWrapper's environment during the build process, not the
constructed wrapper script's environment after installation, and 2. That
change was apparently accidentally lost when merged with 7ff6eec5fd.
Rather than trying to fix the bug again, we remove the extraFlagsArray
feature, since it has never been used in the public repo in the ten
years it has been available.
wrapAclocal continues to use its own, separate flavor of extraFlagsArray
in a more limited context. The analogous bug there was fixed in
4d7d10da6b in 2011.
This is a partial revert of #58715. Bumping the default caused problems
described in #69213. I tested that the vscode corruption happened even
with the 0.10 pre-release, so I'm keeping patchelfUnstable on 0.10
(patchelfUnstable shouldn't cause a large rebuild anyway)
