8:13 a.m.
On Tue, May 30, 2023, 3:13 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
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.
I presume that the name change would be considered a breaking change, since
any applications using the system libraries expecting that name would not
install properly (outside of Fedora packages which could be updated
together with the change). This in spite of the fact that the actual API is
fully compatible. That is the one case that seems like it might be worth
while to add this second distinfo.
> So what is the appropriate course of action here?
Please, attempt to change the dependents.
Since the requires generally come from the package metadata itself, does
this mean changing upstream for each dependency? Or just patch for our
Fedora packages? Presumably they could be patched and then built together
with the updated name, I presume this is where side tags come in to play?
(It'll be a new experience for me!)
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok