PCYMTNQREAIYR (Was Re: cygwin packaging approach for atlas3.6 and lapack3)

Igor Pechtchanski pechtcha@cs.nyu.edu
Mon Jun 27 13:55:00 GMT 2005

On Mon, 27 Jun 2005, Gerrit P. Haase wrote:

> Brian Dessent wrote:
> For the record:
> > On the issue of not having future binary packages blow away a
> > source-compiled optimized version, you could do something similar to how
> > the gcc-mingw-* packages work.  Those packages unpack to a single .tgz
> > file and postinstall/preremove scripts that extract/remove
> > (respectively) its contents to the proper location.  It's an extra level
> > of indirection in the packaging. (I'm not entirely sure why this is done
> > but I think it is a convenience so that the upstream mingw binary
> > tarballs can be used without repackaging.)
> Not exactly true, repackaging is still needed for gcc-mingw since the
> used paths are different.  The main reason is that extracting the
> packages would fail if the directory usr/i686-pc-mingw (and links
> inside) is missing, so the postinstall script creates this directory
> and links first before the tarball is extracted.

I'm not sure that's necessary.  This depends on the paths you use in the
tarball.  If you place the headers into usr/include/mingw, the libraries
into usr/lib/mingw, and the binaries into usr/i686-pc-cygwin/bin (instead
of usr/i686-pc-mingw32/{include,lib,bin}, respectively), there won't be a
need to create the symlinks before extracting the tarball.  Since you
repackage anyway, this should work.
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

More information about the Cygwin-apps mailing list