#8 Require any Python version of the Python packages
Merged 3 years ago by ngompa. Opened 3 years ago by churchyard.
rpms/ churchyard/rpmdevtools require_no_python_version  into  rawhide

file modified
+8 -5
@@ -1,6 +1,6 @@ 

  Name:           rpmdevtools

  Version:        9.3

- Release:        4%{?dist}

+ Release:        5%{?dist}

  Summary:        RPM Development Tools


  # rpmdev-setuptree is GPLv2, everything else GPLv2+
@@ -43,10 +43,10 @@ 

  Requires:       gawk

  Requires:       grep

  Requires:       rpm-build >=

- Requires:       python%{python3_version}dist(argcomplete)

- Requires:       python%{python3_version}dist(progressbar2)

- Requires:       python%{python3_version}dist(requests)

- Requires:       python%{python3_version}dist(rpm)

+ Requires:       python3dist(argcomplete)

+ Requires:       python3dist(progressbar2)

+ Requires:       python3dist(requests)

+ Requires:       python3dist(rpm)

  Requires:       sed

  Requires:       emacs-filesystem

  %if 0%{?fedora}
@@ -120,6 +120,9 @@ 




+ * Mon Feb 15 2021 Miro Hrončok <mhroncok@redhat.com> - 9.3-5

+ - Require any Python version of the Python packages


  * Wed Jan 27 2021 Fedora Release Engineering <releng@fedoraproject.org> - 9.3-4

  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild


When we update Python, rpmdevtools should not need a rebuild.
They install to Python version agnostic directories.

Hence, they need python3dist() packages, not python3.Xdist().

Oh, we need to actually have this built in rawhide, so I'll bump.

rebased onto 5e5734d

3 years ago

Why should I accept this? Normally, we generate Python versioned dependencies, and we only don't in here because I don't have setuptools in it yet...

This would also be a problem in a multi-Python world, because the interpreter would definitely be locked to a specific one.

So, the shebang is /usr/bin/python3 -- hence the python version this needs are the python3dist versions. Even in multi-Python word.

The Python versioned dependencies only make sense for packages that require python(abi) = X.Y or /usr/bin/pythonX.Y or libpythonX.Y. This package does not. Does that make sense?

On Fedora, that doesn't happen, but on RHEL/ELN, it would, since that's what the macro is set to.

I am confused. On RHEL/ELN, what macro is set to what?

Suppose we update the main Python in Fedora to 3.10, but we also add a paralel installable Python 3.9 stack. rpmdevtools requires:

/usr/bin/python3 --> Python 3.10

It will install just fine, but won't function, because it will try to load argcomplete, progressbar2, requests, rpm for Python 3.10, which won't be (necessarily) installed.

Suppose we update the main Python in Fedora to 3.10, and we don't add a paralel installable Python 3.9 stack. rpmdevtools won't install, it will have broken dependencies.

Both scenarios will be fixable by rebuilding rpmdevtools. However, the only reason for the need to rebuild rpmdevtools when we update Python are those requires on pythonX.Ydist(...). I think that they create an artificial need for rebuild - the package is actually otherwise perfectly Python version agnostic (assuming Python 3) when it comes to filesystem locations and shebangs etc.

If you strongly disagree, I am not ready to die on this hill. We could adapt our rebuild tooling not to look for dependencies on Python X.Y only but also to look for any pythonX.Ydist(...) dependency as well. I just don't think we should need to do that.

Same data.

$ time repoquery --repo=koji --source --whatrequires 'libpython3.9.so.1.0()(64bit)' --whatrequires 'python(abi) = 3.9' | pkgname | env LANG=en_US.utf-8 sort | uniq > python310.pkgs

real    0m0,830s
user    0m0,754s
sys 0m0,119s

$ time repoquery --repo=koji --source --whatrequires 'libpython3.9.so.1.0()(64bit)' --whatrequires 'python(abi) = 3.9' --whatrequires 'python3.9dist(*)' | pkgname | env LANG=en_US.utf-8 sort | uniq > python310_dist.pkgs

real    0m28,037s
user    0m27,913s
sys 0m0,101s

$ LANG=en_US.utf-8 comm -13 python310.pkgs python310_dist.pkgs

(Yes, I believe netbox is also wrong in doing this.)

(The times are provided just as a side note, I don't do this because of extra 27 seconds.)

Pull-Request has been merged by ngompa

3 years ago