[Pkg-scicomp-devel] Bug#578052: Bug#578052: Bug#578052: [atlas] providing >20 separate optimized library packages is insane

[Sylvestre Ledru]

Le vendredi 16 avril 2010 à 15:34 +0200, Fabian Greffrath a écrit :
> Am 16.04.2010 14:45, schrieb Sylvestre Ledru:
> > Well, some people do not agree on this.
> > I think it is important to let the user select the appropriate
> > optimisation for his computer.
> 
> Yes, but since by default only the standard non-optimized library 
> packages get installed, it will always require manual intervention to 
> actually make use of optimizations. If you let the linker select the 
> appropriate library it is the other way round: You always benefit from 
> optimizations, unless you explicitely prevent it.

By the way, in all cases, the best optimization will be to build custom
packages of atlas. By design, prebuilt packages of Atlas are not the
best solution.

> > I believe that a user looking for performances on tool based on BLAS
> > implementation (R, Scilab, Code Saturne, etc) is aware that it is
> > related to the CPU they have.
> 
> OK, a skilled user may be expected to know details about his computer 
> architecture. But does he also necessarily have to know about Debian's 
> update-alternatives mechanism and how to use it to actually make use 
> of the special libraries?
The previous mechanism was to play with LD_LIBRARY_PATH. I consider this
solution a strong improvement for "lambda user".

> > However, if I understand correctly, this would mean that I would have to
> > ship all libraries into a single package or to add some Depends on the
> > base package, isn't it ?
> 
> I'd prefer to put them all into a single package and leave the other 
> packages as transitional ones simply depending on the new 
> "all-inclusive" package.
I can provide you a compromise here. 
Beside the current packages, I can try to do a package called
libatlas3gf-all 
which will contain all the various optimisation. The ld stuff would be
done in this package.


> > The separation has been in Debian for a very long time (more than 10
> > years) and it is the first strong complain that I see about that (I know
> > it is not an argument for not doing it).
> 
> Oh, really? I didn't know! From reading your blog post I was under the 
> impression that the separation was also another new feature that you 
> just introduced with the upload of 3.8.3. I must have misunderstood 
> it. However, as you noticed yourself, tradition is not a reason 
> against improvement. ;)
Beside the refactoring and the new upstream release, what I did was to
replace the "LD_LIBRARY_PATH way" by update-alternatives.

Sylvestre