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
