On Sat, Sep 09, 2017 at 09:28:23PM +0200, Sébastien Villemot wrote: > In the process of multi-archifying our BLAS and LAPACK packages (src:lapack, > src:atlas, src:openblas), I realized that there is now a src:clapack package in > the archive, maintained by our team. > > There is an immediate issue that needs to be solved (see #874802 and #874803), > but this is not the topic of this email. > > Looking at the code of src:clapack, I understand that it is an automated > translation into C of the Fortran codebase of src:lapack. > > Said otherwise, it actually provides exactly the same Fortran API as > src:lapack. So this package should not be needed: any program linking against > clapack should be able to link as well with lapack (and would moreover be then > able to benefit from the optimized implementations of ATLAS and OpenBLAS). > > Additionally, the name libcblas-dev is very confusing, because this package > does not provide the standardized C API for BLAS, which happens to be called > “CBLAS” (and which is provided by libblas3, libopenblas-base and > libatlas3-base). > > Finally, one can question the DFSG-freeness of src:clapack, since the C code > that it contains is not the preferred form of modification (the latter actually > being the codebase of src:lapack). > > So, all in all, my understanding is that src:clapack is both useless and > not-totally-DFSG-free, and I would be in favor of its removal, unless I am > missing something. I forgot to mention that clapack is a translation of version 3.2.1 of lapack, which was released in 2009. So the package is clearly not maintained upstream anymore, and contains lots of bugs that have since been fixed in the Fortran codebase. One more reason to remove it. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ http://www.debian.org
Attachment:
signature.asc
Description: PGP signature