[debian-gcc snipped from CC list]
Hi Matthias,
Lots of thanks to you and Camm for all your work! It is great that
these packages are entering unstable -- the gfortran transition should
speed up a lot now. The proliferation of NMUs and updates is a little
confusing, though. Let me try to summarize my understanding of the
current situation, and please tell me whether you and Camm think I'm
correct on the points below. After those four points, I also have a
couple suggestions for things that might be oversights (or might just
reflect my confusion).
As soon as your new NMUs of the lapack and atlas packages have passed
through NEW into Sid, the following will hold:
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"
These dependencies do not need to be versioned since the
libatlas-base-dev, liblapack-dev and libblas-dev binary package names
are new and have never been built with a FORTRAN compiler older than
gfortran-4.3. Also, in principle the alternatives for the atlas and
virtual packages may be omitted for simplicity:
Build-Depends: gfortran (>= 4:4.3), libblas-dev, liblapack-dev
(I'm presuming that it's better for buildds to install the lapack/blas
reference implementations than to install the larger ATLAS packages,
whose liblapack.so/libblas.so files are also in a directory not searched
by default by ld.)
Since libblas-dev is now alphabetically before liblapack-dev, atlas
should no longer get pulled in automatically by buildds.
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"
[1] http://lists.debian.org/debian-toolchain/2007/11/msg00003.html
Should there also be a gfortran versioned dependency here? 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 ?
3) runtime library dependencies: should be generated automatically in
the normal way with "Depends: ${shlibs:Depends}"
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).
Now I mention two things that might possibly be oversights:
A) The liblapack-dev package in your tmp directory Depends on
atlas-base-dev | libblas-dev | libblas-3gf.so -- I think the first of
those should be libatlas-base-dev now, right?
B) It looks like shlibs files of liblapack3gf and libblas3gf now supply
the reference package names before the ATLAS runtime libs package in the
dependencies:
liblapack 3gf liblapack3gf | liblapack.so.3gf | libatlas3gf-base
libblas 3gf libblas3gf | libblas.so.3gf | libatlas3gf-base
Is this intentional? It means that users installing a package that uses
liblapack.so.3gf will no longer get ATLAS runtime libs by default
(unless they have already installed ATLAS manually), but will instead
get the (slower) reference implementations.
My suggestion (of course I may be overlooking something) is to implement
the following:
a) In shlibs file of libblas3gf:
libblas 3gf libatlas3gf-base | libblas3gf | libblas.so.3gf
b) In shlibs file of liblapack3gf:
liblapack 3gf libatlas3gf-base | liblapack3gf | liblapack.so.3gf
c) In Depends stanza of liblapack3gf (implemented via shlibs.local or
however)
Depends: ..., libblas3gf | libatlas3gf-base | libblas.so.3gf
(this is to implement my suggestion in [2], that users explicitly
installing the reference implementation of LAPACK probably also
want the reference implementation of BLAS)
[2] http://lists.debian.org/debian-toolchain/2008/01/msg00019.html
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