gfortran transition release goal proposal
G77 to Gfortran Transition
We would like to present the G77 to gfortran transition as a Lenny
release goal. The Debian developers responsible for the transition
are Riku Voipio <firstname.lastname@example.org> (fortran application and library
packages) and Mathias Klose <email@example.com> (toolchain packages).
* Why do we need one
Upstream did release the last version of the g77 frontend with
GCC-3.4. gfortran 4.2 is now considered a viable replacement for g77.
However, code must not link at the same time against -lg2c and
-lgfortran. To allow partial upgrades we need to rename all library
packages built with g77 and linked against g2c when they are rebuilt
Once the transition is completed, we are able to remove GCC-3.4 from
the distribution (gpc needing an update for GCC-4.1 as well).
If your package build-depends on g77, you need to adjust your
build-depends from g77 to gfortran. If you build-depend on a library
package containing a shared library linked against libg2c, wait until
all of these libraries are rebuilt with gfortran. Tighten the
build-depends on those lib*-dev packages to the first version built
If your package provides a library that exports fortran functionality,
it needs to be renamed. The recommended suffix for the new package
name is "gf". If your package is affected by also by the long double
transition, you can choose whichever suffix for your library.
For example, lapack3 is now:
Binary: lapack3, lapack3-test, lapack3-dev, lapack3-pic, lapack3-doc
Build-Depends: debhelper (>= 4), g77, refblas3-dev
Binary: lapack3gf, lapack3-test, lapack3-dev, lapack3-pic, lapack3-doc
Build-Depends: debhelper (>= 4), gfortran, refblas3-dev (>= <first version built with gfortran)
Some of the command line options supported by g77 have been dropped. You
can usally just drop them.
On ia32 and amd64, you might need to use the -ffloat-store option for
gfortran to achieve identical behaviour with floating points. This was
at least the case for refblas3.
* Affected packages
For the trivial packages, which build-depend on g77 but do not use or
provide fortran libs, replace g77 with gfortran in build-depends and
Aurelien Jarno <firstname.lastname@example.org>
Steinar H. Gunderson <email@example.com>
* pvm (g77 only used for example code.)
Radovan Garabik <firstname.lastname@example.org> (MIA)
Kurt Roeckx <email@example.com>
James R. Van Zandt <firstname.lastname@example.org>
Chris Lawrence <email@example.com>
Justin Pryzby <firstname.lastname@example.org>
The main knot to open is refblas3 -> lapack3 -> atlas3. It expands
with scalapack, octave, netcdf, mpich and lam.. Then, a bunch of python
packages, python-numpy, python-numeric etc need these as well. The actual
details of upload order are still under work.
Camm Maguire <email@example.com>
Adam C. Powell, IV <firstname.lastname@example.org>
Debian Scientific Computing Team <email@example.com>
Kevin B. McCarty <firstname.lastname@example.org>
Paul Brossier <email@example.com>
Warren Turkal <firstname.lastname@example.org>
Debian Octave Group <email@example.com>
"Leaf" packages, that can be uploaded as soon as all their
dependencies have been transitioned.
Christophe Prud'homme <firstname.lastname@example.org>
Daniel Baumann <email@example.com>
Michael Banck <firstname.lastname@example.org>
Adam C. Powell, IV <email@example.com>
Matthias Klose <firstname.lastname@example.org>
Konstantinos Margaritis <email@example.com>
Debian Scipy Team <firstname.lastname@example.org>
Hamish Moffatt <email@example.com>
Debian QA Group <firstname.lastname@example.org>
Henning Glawe <email@example.com>
Muammar El Khatib <firstname.lastname@example.org>
Nicholas Breen <email@example.com>
Mark Hymers <firstname.lastname@example.org>
- MIA or inactive maintaintainers
React with timely NMU's
- Slow NEW que
Renames require visit in NEW. run packages via experimental first
to avoid breaking sid for long times?
- Upstream support
gfortran-4.2 upstream seems enthusiastic about letting g77 to it's
rest, so good support is expected. Individual fortran software might
be quite old upstreams can be inactive.
- gfortran-4.2 on ports
There is a risk that both gfortran upstream finds it uninteresting
to fix bugs in strange ports, while porters remain uninterested in
fortran. It needs to be shown to people that major parts of debian
still have dependencies to fortran packages.
* Feedback and Further discussion
In case we have missed something, you have some sugestions or other
feedback for the release goal proposal, please use the
"rm -rf" only sounds scary if you don't have backups