--- Charles Wilson wrote:
> As I stated in my earlier message, I've no objections to /usr/lib/lapack > -- you're the maintainer. However, there are a few nits: > > (1) aren't there some header files that need to be packaged, as well? Actually, no. lapack and blas are fortran77 libraries, and fortran77 doesn't require headers. Now if I were delivering a cblas library, headers would be required (cblas is a c interface to the blas). What could reasonably be desired are man pages for all the routines, as well as some kind of index. Debian supplies this stuff in a separate lapack-doc package. If there is demand for it, I suppose I could do something similar. Most people can get what they need by browsing the html documentation at netlib. > (2) the documentation directory should't include the REL number (e.g. > /usr/share/doc/lapack-3.0/ not /usr/share/doc/lapack-3.0-1/ > (3) ditto the cygwin specific README > /usr/share/doc/Cygwin/lapack-3.0.README OK. Since apparently there hasn't been an upload yet, I'll just fix that before there is. > > I would also mention that you might (but I doubt it; see below) find it > necessary to adopt the "typical" DLLPkg-mainPkg-develPkg separation... > > > This is necessary, if, for instance, the blas or lapack interface > changes, and you want to release a new version of the DLLs -- but some > people might be using your old octave, or *some other client they > compiled themselves which you do not control* which needs the old > interface and the old DLLs. If they blindly upgrade to the "new" > package, without any safegaurds like this > DLL-in-separate-package-with-vernums scheme (liblapackN not liblapack; > cyglapack-N.dll not cyglapack.dll), then that upgrade will break their > clients. > [...snip...] > Back on point: regardless, you do NOT need to do anything this fancy > right now. In fact, you may never need to -- since lapack/blas is so > stable. > Yes, I could make the package name lapack3, and so forth. Tell you what: I'll append the version number when upstream releases a new version ;). Actually, atlas is in development. It is possible a new stable release will come out in the not too distant future. This wouldn't change the cygwin binary package though; only the source package. The binary package will always supply the blas reference implementation from lapack. If I update the source package with new atlas source, I'll probably just increment the cygwin release digit. Thanks for giving all this a careful vetting. Jim Phillips
