[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

fw: gfortran transition release goal proposal

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 <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


-- 
To UNSUBSCRIBE, email to debian-toolchain-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

--- End Message ---

Attachment: signature.asc
Description: Digital signature

Reply to: