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 defaults.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 requirements.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 tests?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 4.5.
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.
Matthias