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

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.


Reply to: