Description of problem: The current provides of python3-pyxattr-0:0.7.1-3.fc32.x86_64 are: python-pyxattr = 0.7.1-3.fc32 python3-pyxattr = 0.7.1-3.fc32 python3-pyxattr(x86-64) = 0.7.1-3.fc32 python3.8dist(pyxattr) = 0.7.1 python3dist(pyxattr) = 0.7.1 however when a package is built that uses import xattr the requirements are auto calculated as e.g from python3-collectd_cvmfs-0:1.2.2-5.fc32.noarch collectd-python python(abi) = 3.8 python3.8dist(psutil) python3.8dist(xattr) python3dist(psutil) python3dist(pyxattr) The "python3dist(pyxattr)" is something I have added but the "python3.8dist(xattr)" is auto magically added and is not satisfied by the package python3-pyxattr-0:0.7.1-3.fc32.x86_64 Version-Release number of selected component (if applicable): python3-pyxattr-0:0.7.1-3.fc32.x86_64 How reproducible: Every time Steps to Reproduce: 1. dnf install python3-collectd_cvmfs Actual results: Problem: conflicting requests - nothing provides python3.8dist(xattr) needed by python3-collectd_cvmfs-1.2.2-5.fc32.noarch Expected results: Package should install Additional info: Relevant guidelines. https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_automatic_provides_with_a_standardized_name Now I am bit confused by https://pypi.org/project/xattr and https://pypi.org/project/pyxattr but certainly the package python3-pyxattr-0.6.1-2.fc31.x86_64 is the package that allows import xattr so that must be the PyPi name?
Quick workaround in dependent packages is: https://src.fedoraproject.org/rpms/python-collectd_cvmfs/c/32ca8737fb62dff329a66862270f8ef2d853668f?branch=master A quick fix would be I think to add Provides: %{py3_dist xattr} but I think there must be a mismatch with package metadata.
Well, this is an extension... but I would expect python's auto provides to note it? Adding churchyard here for his/the python sigs thoughts...
> Provides: %{py3_dist xattr} Never never never do this. xattr and pyxxatr are different packages. https://pypi.org/project/xattr/ https://pypi.org/project/pyxattr/ The import paths have nothing to do with the provides, it's the package names. Unfortunately, package names don't always correspond with import names. For example python3-setuptools have a pkg_resources module, but they don't provide python3dist(pkg_resources), they only provide python3dist(setuptools). For example python3-django-rest-framework has a rest_framework module, but it doesn't provide python3dist(rest_framework), only python3dist(djangorestframework) (the dashes are missing because the python3-django-rest-framework RPM actually packages a djangorestframework, not django-rest-framework (%global pypi_name djangorestframework)). If you manually provide %{py3_dist xattr}, packages that need xattr will drag in your package, but they will not work properly in case they use setuptools entry_points, because the xattr package is not considered installed from Python PoV. To see the problem, install python3-pyxattr and run `python -sm pip freeze | grep xattr`: $ python -sm pip freeze | grep xattr pyxattr==0.7.1 See, there is no xattr, just pyxattr. This is a duplicate of bz1671697. I am not marking it as such in case you want to workaround this in collectd_cvmfs.
If the package indeed works with pyxattr, a proper workaround is not this: https://src.fedoraproject.org/rpms/python-collectd_cvmfs/c/32ca8737fb62dff329a66862270f8ef2d853668f?branch=master But patching (sedding) the upstream metadata to require pyxattr instead of xattr. But note that upstream has decided that they need xattr, not pyxattr. Maybe the have a reason.
Makes sense, thanks. I wonder though what happens if someone has both these installed? Which xattr*so file loads when you 'import xattr' ? I guess it's academic since the other one is not packaged (yet).
If there are no file level conflicts on the RPM level, and one has a xattr directory while the other one has xattr.so, one of them will take precedence. Which one is it, I don't know from the top of my head, but might be defined in https://docs.python.org/3/reference/import.html Either way, they should explicitly conflict in that case. Note that xattr seem to a have a compatibility layer with pyxattr, so it could in theory replace pyxattr if we want to do that.
Sorry for not responding for so long, but what should we do about this? From my POV this is not a bug in the way we package pyxattr but more a result of the issue that pyxattr is intended to be a drop in replacement of xattr.
Analyze what packages in Fedora depend on (py)xattr. Figure out which project is better to be used here. Can one of them be used for all packages from the above? If so, package that one to replace the other and add necessary metadata patches for the packages that upstream-require the other. If not, package both, and make them explicitly conflict.
> But patching (sedding) the upstream metadata to require pyxattr instead of xattr. In this case I am upstream for collcetd_cvmfs as well so can change that. We are using pyxattr clearly in fedora. Thanks for explanations.
Sorry for delay. https://github.com/xattr/xattr (https://pypi.org/project/xattr/) and https://pyxattr.k1024.org/ (https://pypi.org/project/pyxattr/) are different packages, so I agree that pretending pyxattr provides xattr could backlash in the future, assuming those two project are/will be incompatible. xattr doesn't seem to be packaged in Fedora, so for upstream projects that are being packaged in Fedora a packager could test (and) preferably consult with upstream if pyxattr could be used instead and if yes, use it in Fedora by patching it. Probably a fallover in the upstream build script would be best for reliability, however, it generates some burden with testing with two variant, etc. The unfortunate is that pyxattr uses xattr.so the same as xattr. I don't know if is it technically achievable to work with the upstream (one or both) to make it distinguish and to prevent backward compatibility for already existing packages. However, I have to admit, I'm not a Python developer and I might not crasp all the niuanse of dependency management in Python.
so for upstream projects that are being packaged -> so for future projects that are being packaged
Upstream collectd_cvmfs 1.3.1 now has a setup.py install_requires = [ 'pyxattr', 'psutil', 'scandir;python_version<"3.5"' ] and all related Requires have been removed. So from my narrow point of view this is closed . The original question "AutoProvides and or subsequent Requires for pyattr are wrong ?" The answer is no they are not.