This is a tracking bug for Change: Avoid /usr/bin/python in RPM build
For more details, see: https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build
Deprecate, and later disable, running /usr/bin/python (as opposed to /usr/bin/python3 or /usr/bin/python2) during RPM build.
Changes will be driven by Python SIG, but a few packages may fail to build (with the failure message providing an easy workaround).
We cannot rebuild python2 due to the gcc8 change. Adding a dependency here in BZ to track the situation.
On 2018-Feb-20, we have reached the Fedora 28 Change Checkpoint: Completion deadline (testable).
At this point, all accepted changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be enabled at Change Completion deadline as well.
Change tracking bug should be set to the MODIFIED state to indicate it achieved completeness.
Incomplete and non testable Changes will be reported to FESCo for 2018-Feb-23 meeting.
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.
/usr/bin/python in RPM build is now deprecated. Packages build, most packagers probably just ignore the warning. I don't think we will be able to make it error during this release. However, no analysis have been performed.
Either we say the deprecation makes the change testable and complete and we make the error in another Fedora change for later release, or we say the error was hard requirement for this change and we delay it. Not sure how to deal with that.
I'd say delay it to next release. See the Contingency plan:
If everything goes smoothly, but there is still a significant number of packages failing the check, the switch that would render all of them FTBFS will happen in the next release.
Hint: In GNU documentation for automake, it states for the AM_PATH_PYTHON macro in configure.ac:
If the PYTHON variable is set when AM_PATH_PYTHON is called, then that will be the only Python interpreter that is tried.
In most cases, this line before the call to configure would fix the issue:
Is it maybe possible to integrate my proposal as a magic fix at a more general level like in the automake or autoconf packages itself?
(In reply to Raphael Groner from comment #7)
> Is it maybe possible to integrate my proposal as a magic fix at a more
> general level like in the automake or autoconf packages itself?
This is exactly the magic we want to avoid. Packager python2 or python3 has to be set and always used explicitly. By automagically making it python2, we have the same trouble as with ambigious python: we can never change the automagic to python3.
Note also the very build-environment defining packages may still
clash with the intermediate state of things ATM: [bug 1558192].
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.
According to the Fedora 29 schedule, today is the deadline for changes to be in a testable state. If your change is ready to be tested, please set the status to ON_QA. A list of incomplete changes will be sent to FESCo tomorrow for evaluation. If you know your change will not be ready for Fedora 29, you can set the version to rawhide and notify email@example.com.
This was obsoleted by https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package