Hi Matthias, thanks for your detailed answer! Matthias Klose wrote: > Kevin B. McCarty writes: >> 1) Build-Dependencies: Packages needing liblapack and libblas to build >> should Build-Depend on "gfortran (>= 4:4.3), libblas-dev | >> libatlas-base-dev | libblas-3gf.so, liblapack-dev | libatlas-base-dev | >> liblapack-3gf.so" > > In the past, there was a build dependency on the libblas-dev and > liblapack-dev only; what is the rationale for this change? This was just to let people build the packages if they have ATLAS installed on their workstation instead of BLAS/LAPACK. If you think it is not important (and you are probably right, what with pbuilder etc. making clean local builds easy), I agree that this simpler form is better: >> Build-Depends: gfortran (>= 4:4.3), libblas-dev, liblapack-dev Regarding the question of whether users will want ATLAS or BLAS/LAPACK installed as the default choice: >> 2) libdevel dependencies: Users will most likely prefer to have ATLAS >> packages installed by default [1]. Hence libdevel packages needing >> liblapack.so and libblas.so should Depend on "libatlas-base-dev | >> libblas-dev | libblas-3gf.so, libatlas-base-dev | liblapack-dev | >> liblapack-3gf.so" > > Is this really wanted? the libblas3gf and liblapack3gf shlibs files > currently don't recommend atlas as the first choice. > >> [1] http://lists.debian.org/debian-toolchain/2007/11/msg00003.html ... it seems that Camm feels most users would rather have ATLAS, because it's in general better-optimized, even though larger. >> And should >> there be a warning to users somewhere, that the liblapack.so provided by >> ATLAS is in a non-default directory, so they will either need to pass a >> -L flag to the compiler, or to explicitly link against the >> "alternatives" symlinks, -llapack-3gf -lblas-3gf ? > > (didn't look, but this is only the case for builds using atlas?) Correct, liblapack-dev and libblas-dev just put liblapack.so and libblas.so into /usr/lib. On the other hand, ATLAS puts them into /usr/lib/atlas, in order to permit parallel installation of the libdevel packages. Then the files /usr/lib/liblapack-3gf.so and /usr/lib/libblas-3gf.so are managed via the alternatives mechanism. But most package build systems are just going to search for plain liblapack.so and libblas.so, and probably would not know by default to have the compiler look in /usr/lib/atlas as well as /usr/lib, nor to try to use the -3gf suffixed .so symlinks. So this is a crucial point: If only libatlas-base-dev is installed, trying to link against -llapack -lblas does not work unless the build system or the user takes special measures. I think this is a problem if the libdevel ATLAS package is installed in preference to the reference implementations libblas-dev, liblapack-dev. Camm, what do you think of this? I know your feeling is that users should by default get ATLAS runtime libs instead of BLAS/LAPACK through shlibs dependencies. But what do you feel about the libdevel packages, given the above point? As far as I know there isn't an easy way to make the compiler look in /usr/lib/atlas by default when -llapack -lblas are passed to ld. (This is unlike the runtime library case, where you just drop a file into /etc/ld.so.conf.d/) Here is a crazy idea: what about having the libdevel symlinks /usr/lib/libblas.so and /usr/lib/liblapack.so (and /usr/lib/libblas.a etc.) themselves be managed via alternatives? Symlinks for the reference implementations, and their actual static libraries, could be put in a directory /usr/lib/netlib/ (or such) if desired. The main downside I can see is that a transition from the current situation to this state of affairs could be quite finicky. >> 4) Parallel installability: New gfortran-based blas/lapack/atlas runtime >> library packages entering Sid may now be installed in parallel with the >> older blas/lapack/atlas runtime library packages based on g77. >> Therefore, if a developer wants to support parallel installability of >> gfortran and g77 versions of his/her own runtime libs, s/he may change >> the sonames and filenames of the gfortran-based runtime libraries as >> well as the package names, and omit the Conflicts/Replaces stanzas in >> the runtime library package control file section(s). > > Yes, this is possible with Camm's choice; however if you look at the > fftw package this not done. Are there any other libraries which are > currently used/referenced which whould be released with lenny in both > g77 and gfortran versions? For backwards compatibility purposes, I don't think it's necessary to keep the g77-based libraries actually as part of Debian for lenny. It ought to suffice (and I'm planning for my packages) to keep parallel installability *possible* for gfortran- and g77-based runtime library packages; not worth bothering for the libdevel packages though. This compatibility would be at the maintainer's choice, assuming that all packages s/he depended on were also parallel-installable. This way users can keep the obsolete g77-based runtime lib packages on their systems, even while installing the new gfortran-based ones. They can also reinstall the old packages from snapshot.debian.net if needed. I'm adding an entry in cernlib's debian/NEWS file to that effect, also advising that users recompile all local code with gfortran. best regards, -- Kevin B. McCarty <kmccarty@gmail.com> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751
Attachment:
signature.asc
Description: OpenPGP digital signature