https://bugzilla.redhat.com/show_bug.cgi?id=1774417 --- Comment #11 from Miro Hrončok <mhroncok@xxxxxxxxxx> --- Generally, we track those efforts via this tracker: bz1287556. I will try to answer your questions here, but please don't block the review on it: > > # 00001 # > > # Fixup distutils/unixccompiler.py to remove standard library path from rpath: > > # Was Patch0 in ivazquez' python3000 specfile: > > Patch1: 00001-rpath.patch > > There's no upstreaming status here? What's up with that? We don't want to upstream this, we want to get rid of it, see https://pagure.io/packaging-committee/issue/886 > > # 00102 # > > # Change the various install paths to use /usr/lib64/ instead or /usr/lib > > # Only used when "%%{_lib}" == "lib64" > > # Not yet sent upstream. > > Patch102: 00102-lib64.patch > > I'm pretty sure I've seen variations of this patch for almost a decade now. > Why hasn't this been upstreamed? We are working on it. https://github.com/python/cpython/pull/11755 > > # 00111 # > > # Patch the Makefile.pre.in so that the generated Makefile doesn't try to build > > # a libpythonMAJOR.MINOR.a > > # See https://bugzilla.redhat.com/show_bug.cgi?id=556092 > > # Downstream only: not appropriate for upstream > > Patch111: 00111-no-static-lib.patch > > Why patch instead of just deleting or subpackaging the file? Historical reasons. Possibly faster build, but not sure. The idea was to get rid of this patch via https://fedoraproject.org/wiki/Changes/PythonStaticSpeedup but that is not happening. We will revisit this one day, but it's not a big priority. > > # 00189 # > > # Instead of bundled wheels, use our RPM packaged wheels from > > # /usr/share/python-wheels > > Patch189: 00189-use-rpm-wheels.patch > > I know this isn't upstreamable, but could you please mark it as such and why? I'll submit a python3 PR shortly. > > # 00251 > > # Set values of prefix and exec_prefix in distutils install command > > # to /usr/local if executable is /usr/bin/python* and RPM build > > # is not detected to make pip and distutils install into separate location > > # Fedora Change: https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe > > Patch251: 00251-change-user-install-location.patch > > This is not upstreamable either? Not really in this form. Ideally, we would PEP this, but time is low... :( > > # 00274 # > > # Upstream uses Debian-style architecture naming. Change to match Fedora. > > Patch274: 00274-fix-arch-names.patch > > This is actually the GCC names. I'm not sure what's going on here, but I > *think* our GCC builds have the architectures mangled. It's not a particular > priority, but I'd like if someone checked with our GCC folks to see what's > up here... Possibly, once everything else is done :D > > # 00328 # > > # Restore pyc to TIMESTAMP invalidation mode as default in rpmbubild > > # See https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/57#comment-27426 > > Patch328: 00328-pyc-timestamp-invalidation-mode.patch > > I know this isn't upstreamable, but please mark it as such and why. PR incoming. > > # In Fedora 31, /usr/bin/pydoc was moved here from Python 2. > > # Ideally we'd have an explicit conflict with "/usr/bin/pydoc < 3", > > # but file provides aren't versioned and the file moved across packages. > > # Instead, we rely on the conflict in python3-libs. > > > > This comment exists with no stuff (Conflicts, etc.) underneath it. Was there > something there before? No, the line that starts with "Instead" describes where to look for those. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
