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

Re: gfortran transition: new lapack and blas questions

Kevin B. McCarty writes:
> > is there a reason not to use dpkg-shlibdeps?
> Since you and Camm both asked this, I should probably answer it.
> Basically I'm trying to get people who install Cernlib meta-packages to
> end up with the refblas3 and lapack3 runtime library packages, rather
> than the ATLAS runtime libraries that take up significantly more disk space:
> refblas3 = 225 kB
> lapack3  = 2.6 MB
> atlas3-base = 6.4 MB
> I can't control what's in these packages' shlibs, but I can put refblas3
> and lapack3 as the first alternative in the meta-package dependency
> line, so that the dependency is already fulfilled by the time APT
> reaches the dependency that has the shlibs.
> For example:
> * the cernlib-core meta-package depends on:
> ... refblas3 | libblas.so.3, lapack3 | liblapack.so.3, paw++, ...
> * paw++ depends on (pulled in by ${shlibs:Depends}):
> atlas3-base | lapack3 | liblapack.so.3, ...
> The end result is that users who install Cernlib via the meta-packages
> end up with only the BLAS/LAPACK runtime libs if they do not already
> have anything satisfying this dependency installed, but nevertheless
> ATLAS will satisfy the dependency if they've already installed it for
> other reasons.
> Do you consider this to be a bad idea?  Should I not mess with things
> this way (so that users will end up with ATLAS by default)?

I think you are right, and refblas3 and lapack3 should not have
atlas3-base as the first choice in the shlibs file (if you optimize
for size, maybe build the libraries using -O2 as
well). python-numeric, python-numpy do the same thing in ints rules
file. So only have atlas3-base as the first choice in the atlas3-base
shlibs file. This way maintainers can build-depend on lapack3-dev (and
build-conflict against atlas3-base-dev) to generate a dependency on
lapack3 only.


Reply to: