lapack 3.0 (OpenGL and ncurses maintainers please take note)
James R. Phillips
Sat Jul 2 04:31:00 GMT 2005
--- 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
> (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
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
> 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
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.
More information about the Cygwin-apps