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
>      /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

More information about the Cygwin-apps mailing list