This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: lapack 3.0 (OpenGL and ncurses maintainers please take note)
- From: "James R. Phillips" <antiskid56-cygwin at yahoo dot com>
- To: Charles Wilson <cygwin at cwilson dot fastmail dot fm>, cygwin-apps at cygwin dot com
- Date: Fri, 1 Jul 2005 21:31:21 -0700 (PDT)
- Subject: Re: lapack 3.0 (OpenGL and ncurses maintainers please take note)
- Reply-to: antiskid56-cygwin at yahoo dot com
--- 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