Code change:
<del> FROM centos:5 </del> <ins> # We use Debian 6 (glibc 2.11, kernel 2.6.32) as a common base for other # distros that still need Rust support: RHEL 6 (glibc 2.12, kernel 2.6.32) and # SLES 11 SP4 (glibc 2.11, kernel 3.0). FROM debian:6 </ins> WORKDIR /build <del> # Centos 5 is EOL and is no longer available from the usual mirrors, so switch # to http://vault.centos.org/ RUN sed -i 's/enabled=1/enabled=0/' /etc/yum/pluginconf.d/fastestmirror.conf RUN sed -i 's/mirrorlist/#mirrorlist/' /etc/yum.repos.d/*.repo RUN sed -i 's|#(baseurl.*)mirror.centos.org/centos/$releasever|1vault.centos.org/5.11|' /etc/yum.repos.d/*.repo </del> <ins> # Debian 6 is EOL and no longer available from the usual mirrors, # so we'll need to switch to http://archive.debian.org/ RUN sed -i '/updates/d' /etc/apt/sources.list &&  sed -i 's/httpredir/archive/' /etc/apt/sources.list </ins> <del> RUN yum upgrade -y && yum install -y  curl  </del> <ins> RUN apt-get update &&  apt-get install --allow-unauthenticated -y --no-install-recommends  automake  </ins> bzip2  <ins> ca-certificates  curl  file  g++  g++-multilib  </ins> gcc  <del> gcc-c++  </del> <ins> gcc-multilib  git  lib32z1-dev  libedit-dev  libncurses-dev  </ins> make  <del> glibc-devel  </del> <ins> patch  </ins> perl  <del> zlib-devel  file  xz  which  pkgconfig  </del> <ins> pkg-config  unzip  </ins> wget  <del> autoconf  gettext </del> <ins> xz-utils  zlib1g-dev </ins> ENV PATH=/rustroot/bin:$PATH <del> ENV LD_LIBRARY_PATH=/rustroot/lib64:/rustroot/lib </del> <ins> ENV LD_LIBRARY_PATH=/rustroot/lib64:/rustroot/lib32:/rustroot/lib </ins> ENV PKG_CONFIG_PATH=/rustroot/lib/pkgconfig WORKDIR /tmp <ins> RUN mkdir /home/user </ins> COPY host-x86_64/dist-x86_64-linux/shared.sh /tmp/ # We need a build of openssl which supports SNI to download artifacts from

Related discussion:
text: It also may be worth to drop support of Windows XP and Vista (especially considering that panics are broken on XP since June 2016, see: ). Previously it was discussed . cc
Besides , which other things would we be able to clean up?
Good question! There are 6 workarounds in for older Linux versions (that I could find). Increasing the minimum version to 2.6.32 (aka 3rd Kernel LTS, aka RHEL 6) would fix 5 of them. Code links are inline: (mentioned above, in 2.6.23) ( in 2.6.24, there is also the mention of a bug occuring on "some linux kernel at some point") to atomically set the flag on the pipe fds ( in 2.6.27) ( in 2.6.27) to permit use of ( in 2.6.28) ( in 4.5, not fixed by this proposal) As you can see, the workarounds fixed by this proposal all have a similar flavor.
I am Red Hat's maintainer for Rust on RHEL -- thanks for the cc. I try to keep an eye on new issues, but this one slipped past me. Red Hat only ships the Rust toolchain to customers for RHEL 7 and RHEL 8. If our customers would like to use Rust on older RHEL, they can do so via , and we'll support them in the same way we would for any other third-party software. Internally we do also build and use on RHEL 6, mostly because it's needed to ship Firefox updates. This is where it gets a little hairy, because each RHEL N is bootstrapped on RHEL N-1 and often kept that way -- meaning a lot of our RHEL 6 builders are still running on a RHEL 5 kernel. I would have to apply local workarounds if upstream Rust loses the ability to run on 2.6.18 kernels. We prefer to keep fixes upstream as much as possible, both for open sharing and to avoid bitrot. Is there much of a benefit to removing the current workarounds? I agree all of that code is annoying and cumbersome, but it's already written, and as far as I know it hasn't been a maintenance burden. Do you see otherwise?