Hello. In Fedora, we have a soft dependency of pip on libcrypt.so.1 with the following comment:
# Some manylinux1 wheels need libcrypt.so.1.
# Manylinux1, a common (as of 2019) platform tag for binary wheels, relies
# on a glibc version that included ancient crypto functions, which were
# moved to libxcrypt and then removed in:
# The manylinux1 standard assumed glibc would keep ABI compatibility,
# but that's only the case if libcrypt.so.1 (libxcrypt-compat) is around.
# This should be solved in the next manylinux standard (but it may be
# a long time until manylinux1 is phased out).
# See: https://github.com/pypa/manylinux/issues/305
# Note that manylinux is only applicable to x86 (both 32 and 64 bits)
Recommends: (libcrypt.so.1 if python3(x86-32))
Recommends: (libcrypt.so.1()(64bit) if python3(x86-64))
Now when we upgraded Fedora 39’s main Python version to 3.12, I wonder if this can be dropped. As far as I understand https://github.com/pypa/manylinux/issues/994 maynlinux1 is no longer supported, hence it should not be relevant for Python 3.12. Is that assumption correct?
(There could possibly be stable ABI manylinux1 wheels using libcrypt.so.1, but I think we can live with that.)
According to Manylinux Timeline there’s still about 10% of packages being published only on manylinux1 (i.e. it is the highest available manylinux version; presumably because those projects never changed to a later manylinux image), but on the consumer side everyone is ready for later manylinuxes.
I think it would be worth considering rejecting manylinux1 uploads to PyPI, at least for Python 3.12, but possibly for a wider range as well. There’s no reason to use manylinux1 for anything on non-EOL python versions.
Yeah, and effectively abandoned, by both distros and its maintainers. Sad to see, but it is what it is.
Not only that, but LSB 5.0, the final version of the spec, still specifies Python 2.4 (released in 2004!!!) as its minimum Python version and considers the Python 2.4.2 docs as its normative Python reference (never mind Python 3).
Bringing things full circle, RHEL 5— upon which manylinux1 was based—was first released 3 years after Python 2.4 and included that version, which was presumably the initial reason those respective Python and libcrypt.so versions were specified in LSB in the first place.
The manylinux1 PEP originally specified that libcrypt was always available, but this issue was discovered a long time ago. I don’t remember if we got around to updating the text in the PEP (and anyway, that PEP was superseded by PEP 600), but auditwheel was definitely updated, so all but the earliest manylinux1 wheels should already be assuming that libcrypt is not necessarily available on the system.
I think Fedora can probably get away with dropping libcrypt? There ought to be very few wheels still in use that rely on libcrypt, and worst case users can always install the compat package themselves.