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
Received on Mon May 05 2014 - 15:14:28 MDT
This archive was generated by hypermail 2.2.0 : Tue May 06 2014 - 12:00:08 MDT