Re: gfortran transition: new lapack and blas questions
Greetings, and please accept apologies for the shortness of time/delay
in reply.
Matthias Klose <doko@cs.tu-berlin.de> writes:
> 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.
> >
Wouldn't the vast majority of users prefer the ~ 10x better
performance? atlas3-base can always be removed by hand if desired --
this is just question of the best default to please the greatest
number of people.
(The idea being, of course, that must blas users are scientific
performance-obsessed hackers rather than pda users :-))
> > 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.
>
The problem here is that the conflict would also have to be against
atlas3-sse-dev, atlas3-v9-dev (on sparc), .... Quite a few packages!
And these can change as new optimizations are added, a very fragile
system. Now if conflicts against virtual packages worked .... (Maybe
it does, actually, given the helpful remark by one poster that apt,
not dpkg, should sort this out. I've never been very good at pointing
apt et.al. at freshly built experimental packages on my local system
-- I sure there is a simple way to do this for testing purposes?)
Take care,
> Matthias
>
>
>
>
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply to: