Bug 1821486
| Summary: | Problems with %py3_dist and alternate Python stacks | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Miro Hrončok <mhroncok> |
| Component: | python-rpm-macros | Assignee: | Lumír Balhar <lbalhar> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | cstratak, j, lbalhar, m.cyprian, mhroncok, orion, python-sig, torsava |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | python-rpm-macros-3.9-7.fc33 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-07-21 11:59:24 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1821489 | ||
Note that we don't use 39 in package names anymore, but 3.9, so this is a bit easier. |
We have a %py3_dist macro in Fedora. It evaluates to python3dist(...) In Fedora, we want python3dist() to be buildrequired, not python3.8dist(), because we want a SRPM created on Fedora 31 to be buildable on Fedora 33. Hence "hardcoding" the Python version to the generated buildrequires of that SRPM is a problem. Hence, the current behavior makes perfect sense. If we add multiple Python stacks and we want to be able to have a "hardcoded Python version" specfile, the requirements rapidly change. Consider the following spec snippet: %global python3_pkgversion 39 %global __python3 %{_bindir}/python3.9 ... BuildRequires: %{py3_dist foo} This buildrequires python3dist(foo) while it should really buildrequire python3.9dist(foo). We could provide an alternate version of the macro, called %py3X_dist that does exactly that. However, the specfile could no longer remain "identical" because in regular specfiles, we would need to use %py3_dist and in special specfiles like this, %py3X_dist. There are 2 possible ways out of this: 1) Modify the behavior of %py3_dist -- when %python3_pkgversion is 3, it produces python3dist(), when %python3_pkgversion is 39, it produces python3.9dist() 2) Keep %py3_dist as is, create %py3X_dist to work as described in (1). A slight problem with both approaches is to derive 3.9 from 39. We could either: - stick a dot after the first "3" (works fine but feels very hackish) - add provides for python39dist() and use those (but the provides keep piling up) - use %python3_version if %python3_pkgversion is not 3 (this is fragile in case %python3_pkgversion is set, but not %__python3) - require yet another macro to be defined (e.g. %__py3_dist_version) The last approach is the most flexible one, but it would require the specs to have 3 global defines: %global python3_pkgversion 39 %global __python3 %{_bindir}/python3.9 %global __py3_dist_version 3.9 That's starting to be complicated... but we can have a high level macro for this that does all of those and possibly others needed for the future, something like: %{python3_version_is 3.9}