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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282079348.13818.3228.ca...@zlarin
