On 12. 10. 24 0:32, Adam Williamson wrote:
> On Fri, 2024-10-11 at 21:29 +0200, Michal Ambroz wrote:
>> Hello Miro,
>> Thank you very much for the tool - I am adding it to toolbox.
>>
>>
>>
>> I actually love the new pyproject macros, but in the past there were some
>> discrepancies between
>> Fedora and EPEL where not everywhere the situation was ready there to switch
>> to pyproject macros.
>> Please have you checked recently how EPEL8-9-10 is doing with the Fedora
>> pyproject macros?
>> Does it make sense to switch over for all current EPELs?
>
> EPEL 8 can't use them. EPEL 9+ can. This is mentioned at the top of
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/ .
>
> On the whole I'd say it makes sense to use pyproject on all other
> branches and have EPEL 8 use the old guidelines, in most cases. You
> *probably* don't want to keep an EPEL 8 branch in sync with Rawhide
> anyway, we're not supposed to do major version bumps and stuff in EPEL.
Pretty much what Adam said. Some details:
Python 3.6 in RHEL 8 is probably too old to handle the Python code in
pyproject-rpm-macros. This could be fixed by changes in that code of it was the
only problem (it isn't).
pip 9 in RHEL 8 is too old to support pyproject-based builds. pips for newer
Python versions in RHEL 8 are more capable.
setuptools 39.2 in RHEL 8 is too old to provide the (default)
setuptools.build_meta:__legacy__ backend. setuptools for newer Python versions
in RHEL 8 are more capable.
RPM 4.14 in RHEL 8 is too old to understand %generate_buildrequires. There is a
EPEL 8 version of the pyproject-rpm-macros package, but it is severly limited
because of this.
tl;dr RHEL 8 is very old. it predates the fundamental principles those macros
were build on. Python packaging has evolved in the past 6 years almost beyond
recognition. RHEL 8 is too old to catch up. We are at a point where we can no
longer build Python RPM packages for EPEL 8 and Fedora form the same spec file,
unless we fill it with %if conditionals.
--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok
Hello Pythonistas,
The old %py3_build and %py3_install macros (201x-era) as documented in [1] use
a deprecated feature of setuptools.
It is highly recommended to use the current %pyproject macros instead as
documented in [2] and [3] sooner than it becomes necessary.
To help you convert your packages from the old Python macros to the new, I
wrote a tool called pyprojectize [4].
The tool is not yet packaged in Fedora, as I release new alpha releases too
often. It is however installable via pip/uv/pipx from PyPI [5].
To use the tool, run `pyprojectize python-foo.spec`. See the README or --help
for further options.
The program only operates on the spec file itself, and hence has limited
knowledge. The resulting spec file is not guaranteed to be buildable and manual
verification and completion of the transition is strongly advised.
If you encounter problems, please report them to the issue tracker [6] or
directly to me.
Happy packaging.
[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/
[2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
[3]:
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/READ…
[4]: https://github.com/hroncok/pyprojectize
[5]: https://pypi.org/project/pyprojectize/
[6]: https://github.com/hroncok/pyprojectize/issues
--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok
Hi!
I'd like some feedback on the following scenario that had caused an implicit
conflict because of moving shared libs from the main package to a subpackage:
| transaction failed: Rpm transaction failed.
| - file /usr/lib64/libtesseract.so.5.4.1 from install of
| tesseract-libs-5.4.1-4.fc41.x86_64 conflicts with file from package
| tesseract-5.4.1-2.fc41.x86_64
The package maintainer's choice of a fix was to add
Conflicts: tesseract < 5.4.1-4
to "tesseract-libs" whereas common packaging practice has been to prefer
a strict dependency instead, with
Requires: tesseract-libs%{?_isa} = %{version}-%{release}
in package "tesseract".
In Fedora packaging we've tried to avoid explicit conflicts for many years.
Searching the guidelines, I only find this entry from 2013, which is
about "acceptable use" but not a strict MUST:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_split…
Could this be revisited and refined as to be clear about the scenario
of a package split? Specifically, _any_ file moved between [sub]packages
could cause an implicit conflict during system updates. As such, explicit
"Requires" have been the primary choice to add a strict dependency. If
an explicit "Conflicts" tag is needed, the guidelines ought to make that
clear.
