Re: gfortran-4.3 the default gfortran compiler, blas and lapack uploaded to unstable
Kevin B. McCarty writes:
> 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"
In the past, there was a build dependency on the libblas-dev and
liblapack-dev only; what is the rationale for this change?
> 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
yes, this looks ok.
> (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"
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
>
> Should there also be a gfortran versioned dependency here?
I don't think so. Note that once the transition is over that we can
hopefully can drop the gfortran-4.1 and gfortran-4.2 packages before
the release.
> 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?)
> 3) runtime library dependencies: should be generated automatically in
> the normal way with "Depends: ${shlibs:Depends}"
yes, depending on the outcome of the shlibs provided with
blas/lapack/atlas libraries.
> 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?
> 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?
thanks, will fix this once it is out of the NEW queue.
> 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.
In the past, I did change that manually in python-{numeric,numarray,numpy}
so that the "simple" libraries are preferred. These packages are used
by non-numbercrunching people as well and are a bit smaller than the
atlas alternatives. Do we really want to have these users install the
atlas libraries?
> 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
see above; I'm fine with that if the majority does want this.
> 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
ok, that is only needed when libatlas3gf-base is the first choice.
Btw, if somebody has interest in implementing
DEB_BUILD_OPTIONS=nocheck for these packages, please email me.
Matthias
Reply to: