This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Igor Pechtchanski wrote:

> As mentioned above (though not very clearly), symlinks to DLLs don't work
> in Windows.  Hard links do, but those are only supported on NTFS, and an
> upgrade will break them anyway.  I can't think of a way to do this without
> a wrapper DLL, but that's why this should stay on the list -- perhaps
> others will be able to find better solutions.

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.)

If you did this with atlas, the postinstall could check for a marker
left by the source-built version (or some other means of checking, like
the md5 of the dlls) and not unpack the unoptimized binary if found. 
That way the user would not have to worry about accidently upgrading the
package and losing the optimized version, and no DLL voodoo would be
necessary.  If you did it right, you could even allow for
packaging-related updates (such as manpage changes, .profile tweaks,
etc.) to be upgraded with the binary package but without clobbering the
any optimized DLLs.

Brian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]