Do we have any spec dealing with poetry? I'm trying to package ,
but I'm stuck here:
+ /usr/bin/python3 -s /usr/lib/rpm/redhat/pyproject_buildrequires.py
--generate-extras --python3_pkgversion 3 -t
Handling poetry>=1.1.4 from build-system.requires
Requirement satisfied: poetry>=1.1.4
(installed: poetry 1.1.8)
Handling tox-current-env >= 0.0.6 from tox itself
Requirement satisfied: tox-current-env >= 0.0.6
(installed: tox-current-env 0.0.6)
ERROR: tox config file (either pyproject.toml, tox.ini, setup.cfg) not found
but the pyproject.toml file is certainly there. Any pointers would be
I've recently finally watched *Still packaging like it's 1999?* from DevConf.CZ
2020 by Florian Festi.
One thing that I've learned is that for many years now, we can do:
Instead of the more traditional:
The same applies to sources.
Should we adapt our examples in the packaging guidelines to prefer this
approach unless the patches/sources need to be referenced by their number in
%prep? It seems simpler.
It has been supported since RPM 4.15 (hence not yet on RHEL 8).
Spurred off of the recent lxqt thread in devel (https://firstname.lastname@example.org...) that bumped the soname for another library in the stack without announcing that one, I looked in the packaging guidelines to see if there was anything about how to represent the soname version in the spec and didn't see anything.
I know I have seen some mention on the devel list about using a global define to set the so version, and then using that in the %files section instead of a glob on the shared library so that an so version bump is caught at build time and errors it without packager intervention, but that doesn't appear to be listed in the packaging guidelines at all. What are people's thoughts on adding a section about handling so versions alongside the soname section? It say to use the global define/no glob method in the spec (although I haven't decided if I think it should be a SHOULD or a MUST criteria). I feel that could help reduce these unannounced breakages that seem to crop up and that are annoying to scramble to fix afterwards.
Thoughts? Or did I overlook a place in the packaging guidelines that already discusses this?
I’m aware that pyproject-rpm-macros can handle license files in many
> %pyproject_save_files can automatically mark license files with %license macro and language (*.mo) files with %lang macro and appropriate language code. Only license files declared via PEP 639 License-Field field are detected. PEP 639 is still a draft and can be changed in the future.
(I also know that there are some packages where no license file is
marked, or where additional license files are needed, and it’s best to
verify with “rpm -qL -p …” before relying on this feature. That’s not at
In a package review, it was suggested that, even when pyproject_files
includes a license file installed in the dist-info directory and marked
with %license, an explicit installation of the license file with a
relative path, such as
> %license LICENSE.txt
might still be needed—under the theory that the license file is supposed
to be installed in /usr/share/licenses.
The Licensing Guidelines simply say that %license must be used, and
don’t mention /usr/share/licenses.
I’m wondering if this question has come up before and if anyone has
insight into whether or not pyproject-rpm-macros’s license file support
is intended to replace manual license file handling.
– Ben Beasley