Is it safe to assume that manylinux1 and Python 3.12 will never be combined?

Hello. In Fedora, we have a soft dependency of pip on with the following comment:

# Some manylinux1 wheels need
# 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 (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:
# Note that manylinux is only applicable to x86 (both 32 and 64 bits) 
Recommends: ( if python3(x86-32))
Recommends: ( 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 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, 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.

CC @mayeut

2 Likes has been worked around for quite some time when using a recent auditwheel (2.1.0 / 2019-07-28).
It does not mean no one’s uploading manylinux wheels using this.
FYI, is part of LSB if I’m reading Future of · Issue #173 · indygreg/python-build-standalone · GitHub correctly so it shall be part of any linux distributions conforming to LSB.

Fedora Linux does not conform to LSB. LSB is severely outdated and e.g. assumes modules from Python 2 are present in Python.

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 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.


I consider this settled then, we will only keep the weak dependency for for Python 3.11 and older.

Thank You all.