Hi all, Am 30.03.22 um 23:14 schrieb Matěj Cepl:
Hello,
Could you please not use `%{?python_enable_dependency_generator}` macro? We have agreed in https://github.com/openSUSE/python-rpm-macros/pull/40 that we will let pythonXdist() symbols be generated only for the compatibility with other distributions.
I don't see any agreement to that effect in that discussion. There is just the notion that it is not that useful for us, so we won't use it. It doesn't help with the BuildRequirements for the obs resolver at all. And when you list the BuildRequirements manually, why not also list the runtime requirements and have a proper human review for them?
Unfortunately for us, this macro expects that the upstream metadata are correctly maintained. The sad reality is that they are not. We have an experience that especially version numbers are quite often just plain wrong (author just wrote the versions of packages he had currently on his drive) and what's even worse, upstream quite often instead of dealing with some issues just add '<4.0' and they think the issue has been resolved.
Not using the macro will not allow you to ignore errors in the metadata. With bad metadata, you will run into pkg_resources and importlib metadata errors soon enough. In the specific case linked by you, the problem is a pattern I have seen tens of times in the last couple of weeks: The rpm packager for subprocess-tee forgot to BuildRequire setuptools_scm and toml/tomli. These are usually specified in setup.py or pyproject.toml as build requirement `setuptools_scm[toml]` and serve as version determinators for the metadata to be installed. Without it, the version becomes 0.0.0 and that is what the generator found. Not upstream's fault at all. If you stop to put catchall lines into the %files section but list a proper %{python_sitelib}/mymodule-%{version}*-info you catch such errors during packaging. I encourage everyone to do it.
However, that creates hundreds of mutually exclusive packages, and it is absolutely impossible to maintain this when we are talking about thousands of packages at once and not enough manpower to keep it all together (just d:l:p is 2087 packages, and 3138 packages with python in name in Factory). We would have to patch hundreds of setup.py files and deal with the upstream pull requests. It is just much more simple just write version numbers in our own metadata.
You have to sync the rpm metadata with the egg/dist-metadata or you will run into aforementioned pkg_resources/importlib errors again and again. See many of the currently failing packages in Staging:M due to a docutils update, which is not compatible with Sphinx. So you either have to unpin the upper bounds in the setup.* or requirements files or work them into the rpm packages.
See https://build.opensuse.org/request/show/965773 for one of many of such issues.
I will remove this macro from all our .spec files, please, do not return them back.
If you properly sync the metadata, and you must, there is no need to remove the generator. Although, as already said, the generator is not very useful within the context of the openbuildservice. - Ben