Re: [MinGW-dvlpr] Standards for Building MinGW Release Packages;

[Greg C. <gch...@sb...>]

On 2008-04-22 01:48Z, Charles Wilson wrote:
[...]
> 'Course, no "normal" native windows tool supports lzma, so we'd have to 
> build support for that into (a) our installer, (b) and provide a native 
> 'mingw' version of tar + lzma, for bootstrapping commandline junkies 
> like me.
> 
> (b) is not hard; we can leverage the old gnuwin32 gnutar (not their 
> present bsdtar), and lzma actually ships a native win32 binary in the 
> source archive.

gnuwin32 gnutar has dependencies on two dlls that it provides:

$cygcheck c:/Program\ Files/GnuWin32/bin/tar.exe |sed -e'/WINDOWS/d'
c:/Program Files/GnuWin32/bin/tar.exe
  c:/Program Files/GnuWin32/bin\libintl-2.dll
    c:/Program Files/GnuWin32/bin\libiconv-2.dll

I wonder whether those dlls would conflict with other versions
that a user might have installed? I keep trying to get the
source in order to see whether it can be built without those
dependencies, but the sourceforge download site is unusually
unresponsive tonight.

> (a) might be harder: lzma decomp is available as a library (actually you 
> just included six or so specific files into your build, it's not 
> distributed as a "library" per se), but I don't know how the current 
> installer achieves its "archive unpacking" functionality. I know that in 
> cygwin setup.exe, you'd just need to write a single derived class that 
> encapsulates the interface to the compression library...

The current installer seems to be NSIS, whose documentation
says it supports lzma:
  http://nsis.sourceforge.net/Features
| three different integrated compression methods (ZLib, BZip2, LZMA)

> However, the advantage would be that we could (a) avoid hardlinks in the 
> tarballs with no size penalty, (b) not have to worry if the mingw tar 
> supported extracting hardlinks properly, by requiring packagers use the 
> --hard-dereference option in tar-1.19.90 when creating packages,

That's especially nice because some people already have an
older 'tar' installed. Only packagers would need the latest.

> and (c) 
> we would *guarantee* that nobody would try to use WinZip to unpack the 
> archive, with its notorious "Smart [that is, extremely dumb] CR/LF 
> conversion" switch.  Which is turned on, by default.

I have my own winzip "war stories" like the one you posted
on the users' list at 02:50Z, and I agree that deliberate
incompatibility with winzip is a desirable feature.