# The next manylinux specification

**URL:** <https://discuss.python.org/t/the-next-manylinux-specification/1043>\
**Category:** Packaging\
**Created:** [March 22, 2019, 7:59pm UTC](https://discuss.python.org/t/the-next-manylinux-specification/1043 "2019-03-22T19:59:25Z")\
**Posts on this page:** 1\
**Showing post:** 239

<div class="post-metadata">

**Author:** ![h-vetinari](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/h-vetinari/32/1220_2.png) [@h-vetinari](https://discuss.python.org/u/h-vetinari)\
**Post date:** [June 9, 2022, 11:42am UTC](https://discuss.python.org/t/the-next-manylinux-specification/1043/239 "2022-06-09T11:42:17Z")

</div>

I think the discussion for the [base image](https://github.com/pypa/manylinux/issues/1282) of 2\_28 showed that it’s good to stay based on RHEL and its derivatives (if only already for the devtoolset backports!). They should all be ABI-compatible anyway, though there’s slight variations (see OP of that discussion). Provided that rhubi 9 comes with a current devtoolset, I think that would be the most attractive option.

It would also continue the pattern so far:

| manylinux | glibc | RHEL |
| --- | --- | --- |
| manylinux1 | 2.5 | 5 |
| manylinux2010 | 2.12 | 6 |
| manylinux2014 | 2.17 | 7 |
| manylinux\_2\_28 | 2.28 | 8 |
| manylinux\_2\_34 | 2.34 | 9 |

There’s a pretty large glibc-gap between RHEL 7 & 8, but the debian-based 2\_24 was struggling with adoption particularly due to the [lack](https://github.com/pypa/manylinux/issues/1012) of modern compilers, and is almost [EOL](https://github.com/pypa/manylinux/issues/1332), so I’m not counting it.

All that being said, I think there’s really no rush for this. The motivating/constraining factor here is not CI usage, but how many users have a new enough glibc (& pip) to consume manylinux\_2\_34 wheels. The [answer](https://mayeut.github.io/manylinux-timeline/) is about 10% of python 3.10 users, and microscopic amounts of all other python users. That is not a reasonable user base (currently) to justify the maintenance effort for most projects to publish such wheels (in constrast, glibc 2.28+ is quite-to-very widespread for everything but python 3.7, which is starting to drop off the radar anyway, cf. e.g. NEP29).

---

_[View the full topic](https://discuss.python.org/t/the-next-manylinux-specification/1043)._