On Mon, 2 Jul 2007 12:39:20 +0530 "Kumar Appaiah" <akumar@ee.iitm.ac.in> wrote: > On 02/07/07, Kumar Appaiah wrote: > > I have a new package ready at: > > http://mentors.debian.net/debian/pool/main/l/libitpp/libitpp_3.99.2-1.dsc > > And I just spoke to upstream about this issue. The author has assured > me that no feature will be missing if I have have LAPACK, BLAS and > FFTW3. This means that I can drop Atlas dependency. However, CBLAS may > prove to be a bit more efficient. But I am not able to find a cblas > implementation for Debian as a separate package. Also, using GSL for > providing cblas would be overkill, and add to the big list of > dependencies. So, what is the course of action you would suggest? > Leaving it as is, or trying for CBLAS? Is this the same cblas as usr/lib/libgslcblas.so.0 in libgsl0 http://packages.debian.org/stable/math/libgsl0 ? It wasn't primarily the size of atlas that concerned me, it was the age, reliance on an old compiler, the non-activity upstream and the RC bugs. libgsl0 may be large but it doesn't bring in any extraneous dependencies. Of lapack, blas and fftw, it is lapack that is the one bringing in the most dependencies via libg2c0 which brings in gcc-3.4 and although it has no bug problems, it is as old as atlas and relies on the same old compiler. Adding libgsl0 to the mix only adds about 2% to the total size of the archives in pbuilder. It only seems to increase the risk of mysterious bugs if you are using two different fortran libraries that are built against *VERY* different compilers : gcc-3.4 and gcc-4.2. Having one package depend on both libgfortran2 and libg2c0 could be a source of weird bugs. As maintainer of libitpp, it will be your job to fix them! (in conjunction with libitpp upstream). GnuCash has had similar problems - even now it still depends on libglib1 because of a dependency on an old library that has not been updated. (The bug report is over a year old now.) These things tend to bite eventually because the old library has to be removed from Debian at some point. lapack would appear to be less of a potential headache than atlas and the way that the libraries are arranged means that atlas is still a usable alternative when installing the binaries. It is just worth being aware that lapack may complicate things when trying to fix bugs in libitpp. I think you could at least try a pbuilder run with--with-cblas=gslcblas enabled in your ./configure arguments. The current --with-cblas=cblas is broken anyway because no libcblas exists without libgsl0. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpOiyOemRfFO.pgp
Description: PGP signature