Atlas proposal

[Sylvestre Ledru]

Hello,

As I presented during the DebConf 10, I would like to change the way we
are packaging Atlas.

Quick remember, Atlas is a linear algebra library implementing the BLAS
API/ABI. It is widely used in the scientific computing world but also by
some spreadsheets (openoffice).
This is an highly optimized library. The optimisation is done at build
time against the hardware it is building on.
The current package provides an easy way to build locally the optimized
packages.

In unstable, the following already optimized packages are:
libatlas3gf-base, libatlas3gf-core2sse3, libatlas3gf-sse2,
libatlas3gf-sse3, libatlas3gf-sse

However, due to the nature of the optimization system (at build time),
the causes three major issues:
* all packages in the archive are optimized for the machine it has built
one
* Atlas could have much better performances on the device it builds on.
* Since the number of threads is statically launchable is computed at
build time, some algorithms on a single core machine could have dramatic
degradations if packages have been generated on a multicore machine.

After some discussions at the DebConf, here is a proposal on what should
be done:
* drop all optimized packages from the archive
* only provide libatlas3gf-base & libatlas-base-dev without any
extension and limited to one thread.
* Update the description of the package with these information.
* During the installation of the package, through debconf, inform the
user that the current package is under optimized and better performances
would be achieved by recompiling locally the package (which takes time
anyway)
* Through the DebConf process, propose to the user to build and install
the optimized package

My main questions are:
* does it sound reasonable ? 
* is it possible to use debconf this way ?

My target is still Squeeze. The current Atlas packages in testing are
not good enough.
I will try to implement my proposal this week. 

Sylvestre