[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: freeze exception for gcc-4.5 (i386, amd64 only)

On 18.08.2010 16:36, Neil McGovern wrote:
On Mon, Aug 16, 2010 at 12:36:34PM +0200, Matthias Klose wrote:
On 11.08.2010 23:16, Neil McGovern wrote:
Hi Matthias,

Sorry for not getting back to you sooner.

On Sat, Aug 07, 2010 at 11:42:42PM +0200, Matthias Klose wrote:
gcc-4.5 should be released with squeeze, at least on amd64 and i386.
gcc-4.5.1 was released a week ago, the first bug and regression fix
release after the initial gcc-4.5.0 release.

Do you have any information as to why this is needed for squeeze, as
opposed to squeeze+1? Would this be a nice-to-have, or does it solve a
specific problem?

it's more than "nice-to-have". See the reasons in my original
posting (which you didn't include here in the reply).

I'm not sure there are any in the original, plugins and a greater
optimisation level certainly aren't things which will solve specific
problems. Could you highlight them for me?

Having these features available for developers, and having not to wait two years until these appear in a stable release is worth the update. Exposing a new compiler version to upstream developers helps reducing the delta between upstream and debian packages. Yes I think this is worth having it in squeeze.

  - gcc-4.5 will be an optional compiler, not replacing the current

Ok, but if it can be used, it probably will be by at least some things.

correct. but it should not introduce rc issues; if it does, then
fall back to 4.4, or don't use 4.5 in the first place.

Unless things FTBFS on some arches and not others, and thus cause delays
in the freeze.

Please specify "things". Remember that I did only propose to enable this for amd64 and i386. I can't see how your statement is specific for this upload, and not for any other package.

If port maintainers do want to enable gcc-4.5 on a port, they should
make sure that no regressions are introduced by building the runtime
libraries from
4.5 and ensure that possible regressions are fixed.

This is the bit that worries me. Although it is optional, it can (and
IMO will probably) be used by at least some things. This could lead to
odd bugs. If there's a problem in GCC 4.5 that isn't in 4.4, and it
comes to a security upload, there could be a mismatch between the

sorry, I don't understand this reasoning and the implications for
security uploads. If a package is explicitely built with 4.5, it
will be built with 4.5 for security uploads too.

Ok, assume that gcc4.5 has some major bug that causes FTBFSes in
certain circumstances, and a package has been modified in a way to take
advantage of gcc4.5, specifically so it won't build with 4.4; then a
problem would occur.

Then reverting back to build it with 4.4 should be possible. Again, I don't see this as an argument against it.

Do you have details as to the (previously mentioned) unit/regression

not besides the test results included in the packages prepared for
upload.  Is there anything more you would expect?

You mentioned:
- the upload will build several runtime libraries from the 4.5
   sources.  Regression tests did pass for the runtime libs built
   from the 4.5 sources and for 4.4 using the runtime libs from

This didn't answer my question. "Is there anything more you would expect?"

At the moment, I'm still not sure on the actual advantage of introducing this new package at this stage in the release cycle.

well, currently I don't see any arguments against the upload, just some feelings that could apply to any package.


Reply to: