Hi, The proposal to transition from the outdated g77 to gfortran did not result any comments. Which rises the suspicion that the maintainers of affected packages are not reading debian-release or debian-toolchain.
If you have suggestions, critique, or you are busy but accept NMU'ing your packages for gfortran transition.. please speak now. Some of the packages gfortran transition affects are also affected by the long double transition. This includes atleast the following fortran packages: lam, atlas3, fftw3, hdf5, mpich1.0, petsc, pdl Therefor, I think it would make sense to start g77 -> gfortran transition promptly, to avoid transitioning same packages twice. -- "rm -rf" only sounds scary if you don't have backups
--- Begin Message ---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]
--- End Message ---
signature.asc
Description: Digital signature
