This week, we will change the GCC default versions from 3.3 to 4.0 (for g77 and gpc to 3.4, these are not supported in 4.0) on all architectures. The GCC-4.0 version used is taken from the GCC 4.0 branch (something that will likely become the 4.0.1 release candidate 3). The switch to 4.0 (instead to 3.4) is preferred by the Debian GCC maintainers and the port maintainers (modulo those I forgot to ask, please speak up now). Looking forward at the etch release schedule, it is unlikely that 3.4 is still supported upstream in 18 months. 4.0 is currently used on by other distributions as a system compiler to build most of the distribution. We will keep at least the GCC-3.4 C and Fortran77 compilers for the etch release.
The C++ ABI change was already announced at http://lists.debian.org/debian-release/2005/04/msg00153.html There has been a concern about re-renaming library packages libfoo1c102 back to libfoo1, because this might break third party packages on systems, that are directly upgraded from potato to etch. I don't know any of these, but if a package maintainer thinks it's worth supporting these packages and upgrades, please rename the package to libfoo1c2. In this case you have to keep the libfooc1 conflict/replace and add the libfoo1c102 conflict/replace. The timeframe for the change is as follows: - wait for gcc-4.0 4.0.0-11 in the archives on all architectures, for sparc and hppa we require the -12 version (Looking at the buildds, that probably will be 2005-07-0[56]). - wait for gcc-3.4 3.4.4-3 in the archives on all architectures, although 3.4.4-4 would be preferred (same estimates as for gcc-4.0). - an upgrade to binutils-2.16.1 is a nice to have, currently needs some more work on mips/mipsel. - upgrade gcc-defaults to point to the 4.0 compiler drivers. - upgrade build-essential to version 11 to depend on the new defaults. PLEASE do NOT start uploading packages before a new gcc-defaults and build-essential are in the archives. After these are in the archives: The following can happen in parallel: - Rebuild C++ applications, which do not depend on any other C++ library besides libstdc++. - Rename and rebuild C++ libraries, which do not depend on any other C++ library besides libstdc++. All other applications and libraries have to wait, until the C++ related build dependencies are available for the new ABI. It's important to adjust the build dependencies and the dependencies of the -dev packages to the first version of a package, which is built for the new ABI. Please don't add build dependencies on g++ (>= 4.0) or build-essential (>= 11). The buildd maintainers will take care, that the buildd's run with build-essential-11 after it's in the archives. I'm updating the above mentioned text for the C++ ABI until Wednesday or Thursday. Feedback and additions are welcome. For the time until all C++ libraries are converted, I'm proposing the following NMU policy: - 0-day NMU's allowed for all C++ library packages, which are uploaded after the g++ default change, and are completely ignoring the C++ ABI change. - 2-day NMU's allowed for all C++ library packages, which are uploaded after the g++ default change, with serious bugs in the packaging (i.e. wrong package name in shlibs file, missing conflicts/replaces, library package without a library, etc). - 5-day NMU for all C++ library packages, which can be converted, but are left alone. Matthias PS: Some of you know, that Ubuntu did the C++ ABI change at the start of it's release cycle. For most if the libraries, patches are available. These have to be adjusted, at least for the version numbers. Some Debian developers think these patches are too simple, and it doesn't make sense to submit those to the Debian BTS. All others may have a look at http://wiki.ubuntu.com/CxxLibraryList -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
