RE: [squid-users] Squid 3.4.5 is available

C++11 with the requirement for gcc-4.8 would really be a
show-stopper for most existing systems...

For example RHEL6 still ships with gcc-4.4.7, so a switch there
would result in cutting off Centos/RHEL6 as well.
Even the Debian I have running on my Raspberry Pi only comes
with gcc-4.7.2 as the latest installable option.

Only RHEL7beta ships with 4.8 as far as I can tell. And for that
to go mainstream one will need to wait at least another year after
the official release (which is probably in Q3-2014).

So that would definitely reduce possible audience for any squid
3.5 release that makes use of C++11.

And having people compile gcc and the required dependencies
themselves first is another support-nightmare...

I guess People would more likely stay with the older squid version
(even if they are buggy) than spending that amount of time and
Hassle just to get all the dependencies compiled or even think of
upgrading to a new OS version...

Out of curiosity: which features of c++11 do you want to use to
make gcc 4.8 an absolute requirement for the next major release?

Just my 2 cents

Martin

-----Original Message-----
From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
Sent: Montag, 05. Mai 2014 17:14
To: squid-users_at_squid-cache.org
Subject: Re: [squid-users] Squid 3.4.5 is available

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

This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
Received on Tue May 06 2014 - 06:52:33 MDT