On 6/05/2014 2:09 a.m., Martin Sperl wrote: > Hi Amos! > > Does this mean that squid 3.4.4 is no longer supported on > RedHat Enterprise/Centos 5 (ships with autoconf 2.59)? > RHEL 6 comes with exactly 2.63, so any future update will > mean that RHEL6 may also become unsupported as well. That OS version has been best-effort for some months now. We aim to test on the latest stable, previous stable, and if possible and upcoming/rolling release when we can. For CentOS we test on CentOS 6 and 6.5. > > Just tracking upstream "authconf" is bound to produce similar > pains that I have already experienced with RRDTool on RH3, > RH4, RH5 systems. Yes. We are not tracking "autoconf" upstream itself, but the packaging is now done on a Debian based machine which does have more frequent toolchain updates than our previous FreeBSD 5 machine. On the other hand the C++11 usage is more likely to have an blocking impact on those old RHEL systems. Do they have GCC 4.8 available? at least in unofficial packages. Or can they by Dec? > > I assume that the tar-balls will still get delivered with the > ./configure files, so the "direct" need of autoconf versions > may be less important for lots of people just compiling. > But it still may break at some point resulting in unexpected > behavior - probably during a really important bug-fix > release... Yes, the tar-balls will still be delivered as before. Murphys law dictates that such breakage will occur whatever we do ... > > So I wonder if it is really a wise move to potentially cut off > people from security patches because they can no longer > compile squid on the system they want to use it on just > due to the build-tool dependencies. > > Is there maybe a plan not to change build-tool versions > within a minor version (3.4, 3.5, ...) to somewhat avoid > such issues? ... ironically it is security issues which have prompted this change. Our FreeBSD 5 machine was getting too outdated and un-patchable. The biggest toolchain pains over the last few years have been due to our old toolchain versions having incompatibilities compiling on the more up to date OS distributions. Not least of which is 2-digit version numbers and detecting newer available tools. The aim is to make big changes in the toolchains only with beta release testing. For this change it was done in 3.4.4.1 and 3.4.4.2 beta packages last month. Overall we have to face the same version compatibility issues in the toolchain regardless of which versions we distribute with. At least there is a slightly better chance of backward compatility being embeded in the scripts from updated bundled versions than forward-compatibility being embeded by the old. The toolchain upstream have been making some strong efforts in that direction recent years which adds benefit to this change. For those with very large problems the bootstrap.sh script is available in the repository which can regenerate the build scripts against many older version(s) of the toolchain as a last resort. HTH Amos
