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 <riku.voipio@iki.fi> (fortran application and library
packages) and Mathias Klose <doko@debian.org> (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
with gfortran.
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).
* Actions
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
with gfortran.
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:
Package: lapack3
Binary: lapack3, lapack3-test, lapack3-dev, lapack3-pic, lapack3-doc
Build-Depends: debhelper (>= 4), g77, refblas3-dev
should become:
Package: lapack3
Binary: lapack3gf, lapack3-test, lapack3-dev, lapack3-pic, lapack3-doc
Build-Depends: debhelper (>= 4), gfortran, refblas3-dev (>= <first version built with gfortran)
* Caveats
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
upload.
Aurelien Jarno <aurel32@debian.org>
* med-fichier
Steinar H. Gunderson <sesse@debian.org>
* pvm (g77 only used for example code.)
Radovan Garabik <garabik@melkor.dnp.fmph.uniba.sk> (MIA)
* zivot
Kurt Roeckx <kurt@roeckx.be>
* libtool
James R. Van Zandt <jrv@debian.org>
* minpack
* multimix
Chris Lawrence <lawrencc@debian.org>
* r-noncran-lindsey
Justin Pryzby <justinpryzby@users.sf.net>
* saods9
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 <camm@enhanced.com>
* refblas3
* lapack3
* lam
* atlas3
Adam C. Powell, IV <hazelsct@debian.org>
* mpich
* petsc
Debian Scientific Computing Team <pkg-scicomp-devel@lists.alioth.debian.org>
* ufsparse
Kevin B. McCarty <kmccarty@debian.org>
* cernlib
* geant321
* mclibs
* mn-fit
* paw
Paul Brossier <piem@debian.org>
* fftw
* fftw3
* k7fftwgel
* k6fftwgel
* p4fftwgel
Warren Turkal <wt@penguintechs.org>
* netcdf
Debian Octave Group <pkg-octave-devel@lists.alioth.debian.org>
* octave2.9
* octave2.1
"Leaf" packages, that can be uploaded as soon as all their
dependencies have been transitioned.
Christophe Prud'homme <prudhomm@mit.edu>
* arpack
Daniel Baumann <daniel.baumann@panthera-systems.net>
* lush
Michael Banck <mbanck@debian.org>
* mpqc
* psicode
Adam C. Powell, IV <hazelsct@debian.org>
* pysparse
Matthias Klose <doko@debian.org>
* python-numarray
* python-numeric
Konstantinos Margaritis <markos@debian.org>
* blitz++
Debian Scipy Team <deb-scipy-devel@lists.alioth.debian.org>
* python-numpy
* python-scipy
Hamish Moffatt <hamish@debian.org>
* wsjt
Debian QA Group <packages@qa.debian.org>
* tela
* libextutils-f77-perl
Henning Glawe <glaweh@debian.org>
* pdl
Muammar El Khatib <muammarelkhatib@gmail.com>
* blacs-pvm
* blacs-mpi
* scalapack
Nicholas Breen <nbreen@ofb.net>
* gromacs
Mark Hymers <mhy@debian.org>
* kst
* Risks
- 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
debian-toolchain@lists.debian.org list.
--
"rm -rf" only sounds scary if you don't have backups
Reply to: