Re: gcc 3.2 is now the default compiler in unstable
On Wed, Jan 08, 2003 at 10:38:18PM +0100, "Martin v. Löwis" wrote:
> Because I can :-) Seriously, the current update_excuses mechanism is very
> conservative about migrating things. For example, as long as glibc has
> release-critical bugs, *no* package at all will migrate to testing, since
> they all depend on glibc. Even though changing the default Python has
> completed for many weeks now, migration isn't happening, since a single
> release-critical bug in any Python package, or any package that a
> recently-rebuild Python package depends on can stop migration of all other
> packages.
And they must not migrate to testing until the new glibc does. Not only is
the new glibc the version they were tested with, but they will not run with
the older glibc.
> I haven't checked, but I would expect that migration of gcc-defaults
> itself would render a number of packages in testing uninstallable, because
> they happen to depend on earlier gcc versions (on purpose or by mistake).
> Then, the updating mechanism won't migrate gcc-defaults into testing. So I
> expect that magic is needed to override the conservative updating
> procedure.
I did check:
there:[~] grep-available -nsPackage -FDepends 'gcc ('
gcc-2.95
gccchecker
build-essential
and it doesn't look like a problem to me. :-)
> As for needing 6 months for the migration even in unstable: Many
> release-critical bugs will be filed against various packages, as they fail
> to compile or work with g++ 3.2. Fixing those problems will take real
> manpower, delaying the transition by many weeks, per stratum (from
> libstdc++).
Let's wait until these bugs are actually filed before predicting doom, gloom
and the end of civilization as we know it, yes? Keep in mind, gcc 3.2 also
_fixes_ a lot of long-standing bugs in 2.95, and there have been multiple
attempts to rebuild the archive with gcc 3.2 that have been largely
successful (a relatively small number of packages failed to build).
--
- mdz
Reply to: