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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
