On Sun, Sep 10, 2017 at 12:05:36AM +0200, Andreas Tille wrote: > I admit I agree with your arguing (except for the DFSG free-ness since I > trust ftpmaster here). I'm doing a top posting since I just want to > give an in principle unrelated comment about my motivation to package > clapack. I intended to package phast[1] and despite I was close to > finalising it I never pushed it to a final upload. I had a discussion > with upstream (in To:) about clapack and he insisted that this > implementation is needed for phast. I admit I have no idea why this > would be really needed but I'd be happy if Ritika would answer the > arguments below and raise an opinion whether clapack is really urgently > needed or whether the good arguments of Sébastien might be convoncing to > pick an alternative implementation. Depending from this discussion I'm > fine with the removal or will try to push my packaging attempt for phast > to make the existence of clapack at least a bit sensible. Thanks Andreas for your reply. Since clapack and lapack provide exactly the same API and ABI, and actually exactly the same algorithms (the only difference being the programming language in which it is implemented), I have no doubt that phast can directly use lapack. The only value added of clapack over lapack is the clapack.h header, which provides the prototypes for the Fortran LAPACK interface. So in the worst case, phast can be packaged by linking it to lapack, and by providing (a subset of) clapack.h in a patch. Or maybe we could include clapack.h in src:lapack (though ATLAS also provides an unrelated clapack.h, so we must think twice about it). Andreas: in any case, I am willing to help you linking phast with lapack, so that we can get rid of clapack. Best, > On Sat, Sep 09, 2017 at 09:55:59PM +0200, Sébastien Villemot wrote: > > 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 > > > > -- > http://fam-tille.de > -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ http://www.debian.org
Attachment:
signature.asc
Description: PGP signature