Dear Debian Toolchain, I have been trying to follow the happenings on the gfortran transition front, and though I wish to help, I really can't help much in any way other than helping in testing out, mainly due to my lack of knowledge of the toolchain and related issues (Fortran knowledge included), and lack of access to non-x86 architectures. However, I have a few observations and requests, though, which I thought might lead to a discussion and possibly accelerate moving to gfortran more quickly. Here are some notes I wish to make: A look at another distributions (Gentoo) ======================================== I had a look at Gentoo, and saw whether they have solved this problem. Similar to our packages.d.o, they have a nice access system, and even allow us to view the source of their package build scripts (ebuilds) and packages online. So, I had a look, and here are my observations. And note that though the URLs say Gentoo x86, I have confirmed with Gentoo developers that the sources and patches are _architecture independent_, and common sources are used for every architecture, and compiler. Needless to say, it works with gfortran. A final observation is that Gentoo autotoolizes the build procedure, so after patching the upstream source, all they do is ./configure;make etc., and I really find that this is an elegant solution, though this is a decision for maintainers to make. blas-reference ~~~~~~~~~~~~~~ http://packages.gentoo.org/package/sci-libs/blas-reference ebuild: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-libs/blas-reference/blas-reference-20070226.ebuild?view=markup Version: 20070226 This is built from the lapack-lite-3.1.1 tarball available from http://www.netlib.org/lapack/ They have it working for the following architectures: alpha, amd64, hppa, ia64, ppc, ppc64, sparc, x86 Patches: One patch which autotoolizes the build procedure. http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-libs/blas-reference/files/blas-reference-20070226-autotool.patch?rev=1.2&view=log cblas-reference ~~~~~~~~~~~~~~~ http://packages.gentoo.org/package/sci-libs/cblas-reference ebuild: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-libs/cblas-reference/cblas-reference-20030223-r4.ebuild?view=markup Version: 20030223-r4 This is built from the lapack-lite-3.1.1 tarball available from http://www.netlib.org/blas/blast-forum/cblas.tgz They have it working for the following architectures: alpha, amd64, hppa, ppc, ppc64, sparc, x86 (Note that ia64 is missing) Patches: One patch which autotoolizes the build procedure. http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-libs/cblas-reference/files/cblas-reference-20030223-autotool.patch?rev=1.6&view=log lapack-reference ~~~~~~~~~~~~~~~~ http://packages.gentoo.org/package/sci-libs/lapack-reference ebuild: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-libs/lapack-reference/lapack-reference-3.1.1-r1.ebuild?view=markup Version: 3.1.1-r1 This is built from the lapack tarball available from http://www.netlib.org/lapack/lapack.tgz They have it working for the following architectures: alpha, amd64, hppa, ia64, ppc, ppc64, sparc, x86 Patches: Two patches. One patch which autotoolizes the build procedure. http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-libs/lapack-reference/files/lapack-reference-3.1.1-autotools.patch?rev=1.2&view=log And another to disable testing of LS drivers (reason for problem unknown now): http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-libs/lapack-reference/files/lapack-reference-3.1.1-test-fix.patch?rev=1.1&view=log blas-atlas and lapack-atlas ~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://packages.gentoo.org/package/sci-libs/blas-atlas http://packages.gentoo.org/package/sci-libs/lapack-atlas ebuilds: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-libs/blas-atlas/blas-atlas-3.8.0.ebuild?view=markup http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-libs/lapack-atlas/lapack-atlas-3.8.0.ebuild?view=markup Version: 3.8.0 (but many older versions have been retained for some reason) Details omitted, as they can be inferred from the ebuilds. Several patches are available here: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-libs/blas-atlas/files/ http://sources.gentoo.org/viewcvs.py/gentoo-x86/sci-libs/lapack-atlas/files/ Focus on new versions? ====================== If you managed to read the dumped data above, I think you can now see why it is my gut feeling that we should focus on getting the latest upstream releases of packages into experimental and then start asking maintainers to push in the leaf packages into experimental. While I am unaware of all issues which may be involved here, a simple logical argument in support of focusing on the new version would be that for the few packages of concern here, we should remember that some upstream development has been tested on gfortran, and we may be able to make it easier with those versions. Besides, Gentoo has _hardly_ had to make any patches for any architectures for most packages, and we have only a few more architectures than Gentoo, to test, right? Again, I apologize if I've said something which doesn't make too much sense, but I've just tried to make an argument in favour of focusing on the new versions, and getting on with the transition. Thanks! Kumar (hoping nobody flames him on this! :-) -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036
Attachment:
signature.asc
Description: Digital signature