There was code in dnf and dnf-automatic to support running them from
the git tree. This was a developer-oriented hack that should not exist
in production code. It assumed that when running an installed dnf,
the `sys.path[0]` contains `/usr/bin`. If not, it overwrites
the contents of `sys.path[0]`.
This is a problem when running the Python interpreter with the `-P`
parameter (meaning: Don't automatically prepend a potentially unsafe
path to sys.path such as the current directory, the script's directory
or an empty string.)
The fix removes this developer-oriented hack. Developers should instead
set PYTHONPATH in the environment.
See https://bugzilla.redhat.com/show_bug.cgi?id=2057340
and https://github.com/benjaminp/six/issues/359
dnf should never import Python modules from /usr/bin but users can
have files in there that look like Python modules and Python will
try to import them and fail.
Consider a tool that is *not* written in Python and is called "copy.pyc".
Naturally, it resides in /usr/bin/copy.pyc and dnf fails:
Traceback (most recent call last):
File "/usr/bin/dnf", line 57, in <module>
from dnf.cli import main
File "/usr/lib/python3.10/site-packages/dnf/__init__.py", line 30, in <module>
import dnf.base
File "/usr/lib/python3.10/site-packages/dnf/base.py", line 31, in <module>
from copy import deepcopy
ImportError: bad magic number in 'copy': b'...'
Similarly, a tool actually written in Python, called "copy.py"
might as well own /usr/bin/copy.py and dnf fails as well:
Traceback (most recent call last):
File "/usr/bin/dnf", line 57, in <module>
from dnf.cli import main
File "/usr/lib/python3.10/site-packages/dnf/__init__.py", line 30, in <module>
import dnf.base
File "/usr/lib/python3.10/site-packages/dnf/base.py", line 31, in <module>
from copy import deepcopy
ImportError: cannot import name 'deepcopy' from 'copy' (/usr/bin/copy.py)
Either problem can happen for a variety of names.
We better not let that happen.
A more general solution that would prevent Python doing this entirely
does not exists yet, see https://discuss.python.org/t/4235
Hence, proposing this to dnf, which is a critical piece of the system.
The commit should provide identical dnf behavior with dnf and yum prefix. If any
changes in dnf behavior will be required, it should be handled on dnf.conf
level.
https://bugzilla.redhat.com/show_bug.cgi?id=1476748
As DNF have to be more compatible with yum and /usr/bin/yum binary will
be supported longer than was originally planned, we will reduce the
annoying redirecting output
Instead of having separate copies of the dnf and dnf-automatic binaries
for each python version, let's just generate those at build time using
.in files.
Jaroslav Rohel