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 <[EMAIL PROTECTED]> (fortran application and library
packages) and Mathias Klose <[EMAIL PROTECTED]> (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 <[EMAIL PROTECTED]>
* med-fichier
Steinar H. Gunderson <[EMAIL PROTECTED]>
* pvm (g77 only used for example code.)
Radovan Garabik <[EMAIL PROTECTED]> (MIA)
* zivot
Kurt Roeckx <[EMAIL PROTECTED]>
* libtool
James R. Van Zandt <[EMAIL PROTECTED]>
* minpack
* multimix
Chris Lawrence <[EMAIL PROTECTED]>
* r-noncran-lindsey
Justin Pryzby <[EMAIL PROTECTED]>
* 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 <[EMAIL PROTECTED]>
* refblas3
* lapack3
* lam
* atlas3
Adam C. Powell, IV <[EMAIL PROTECTED]>
* mpich
* petsc
Debian Scientific Computing Team <[EMAIL PROTECTED]>
* ufsparse
Kevin B. McCarty <[EMAIL PROTECTED]>
* cernlib
* geant321
* mclibs
* mn-fit
* paw
Paul Brossier <[EMAIL PROTECTED]>
* fftw
* fftw3
* k7fftwgel
* k6fftwgel
* p4fftwgel
Warren Turkal <[EMAIL PROTECTED]>
* netcdf
Debian Octave Group <[EMAIL PROTECTED]>
* octave2.9
* octave2.1
"Leaf" packages, that can be uploaded as soon as all their
dependencies have been transitioned.
Christophe Prud'homme <[EMAIL PROTECTED]>
* arpack
Daniel Baumann <[EMAIL PROTECTED]>
* lush
Michael Banck <[EMAIL PROTECTED]>
* mpqc
* psicode
Adam C. Powell, IV <[EMAIL PROTECTED]>
* pysparse
Matthias Klose <[EMAIL PROTECTED]>
* python-numarray
* python-numeric
Konstantinos Margaritis <[EMAIL PROTECTED]>
* blitz++
Debian Scipy Team <[EMAIL PROTECTED]>
* python-numpy
* python-scipy
Hamish Moffatt <[EMAIL PROTECTED]>
* wsjt
Debian QA Group <[EMAIL PROTECTED]>
* tela
* libextutils-f77-perl
Henning Glawe <[EMAIL PROTECTED]>
* pdl
Muammar El Khatib <[EMAIL PROTECTED]>
* blacs-pvm
* blacs-mpi
* scalapack
Nicholas Breen <[EMAIL PROTECTED]>
* gromacs
Mark Hymers <[EMAIL PROTECTED]>
* 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
[email protected] list.
--
"rm -rf" only sounds scary if you don't have backups
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
