Hi Troy. On 29. 05. 23 18:01, Troy Curtis Jr wrote: > I'm currently working on the update for python-Levenshtein [1] and I have a > question about the best way to proceed. > > In the intervening time since the last release we have packaged, a new > maintainer has taken over maintenance, and built the updates around a stack of > other packages (rapidfuzz-cpp, python-rapidfuzz, scikit-build, etc). Now that > all these dependencies are available I can look to actually do the update. As > part of the updates, the current maintainer has deprecated the original pypi > name of "python-Levenshtein" in favor of the more typical name without the > "python-" prefix. He is continuing to maintain the "python-Levenshtein" pypi > package for compatibility, but now it is just an empty package which defines > "Levenshtein" as a dependency [2]. This means the upstream for the Fedora > python-Levenshtein package must point to the new Levenshtein package in order > to get the actual package contents. However, this means the metadata for the > package indicates the name "Levenshtein" which translate to a provide for > "python3.11dist(levenshtein)", but that is different than the currently > provided "python3.11dist(python-levenshtein)", which current dependencies > require. One option would be to simply manually add a > "python3.11dist(python-levenshtein)" provide, but it seems this seems > specifically prohibited in the Python packaging guidelines [3]. And there is a reason. If the package "claimed" to be python3dist(python-levenshtein), yet the Python metadata would say it's levenshtein, all automation that generates requirements for python3dist(python-levenshtein) would happily accept it, but fail on Python level. For example, the %pyproject_buildrequires macro, when it encounters an unmet dependency on levenshtein on the Python level, prints out python3dist(levenshtein) and restarts for dnf to take over. dnf then installs the package but the macro still does not see the package on Python level, so it prints it out again and restarts... > I think there are 2 options: > - Manually provide the legacy name outside of the python package meta-data Please don't. > - Rebuild all users of the provide to use the new name It's not that many: $ repoquery -q --repo=rawhide{,-source} --whatrequires 'python3.11dist(python-levenshtein)' --whatrequires 'python3dist(python-levenshtein)' paperwork-0:2.1.2-2.fc38.src python-paperwork-backend-0:2.1.2-2.fc38.src python3-paperwork-0:2.1.2-2.fc38.noarch python3-paperwork-backend-0:2.1.2-2.fc38.noarch > The main downside to the second approach is that nothing would provide the > python-Levenshtein name, which is still present and usable via pypi and > perfectly compatible with the current library implementation. But do we need it in Fedora? If you really need this, you could insert a second dist-info metadata to the package, so it would ship: %{python_sitearch}/...actual content here... %{python_sitearch}/Levenshtein-0.21.0.dist-info/ %{python_sitelib}/python_Levenshtein-0.21.0.dist-info/ That way, it provides both names on Python and RPM level both. But I consider that an overkill.

> So what is the appropriate course of action here? Please, attempt to change the dependents.

-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok