Re: [Lzip-bug] [PATCH] lzip on Windows

[JonY]

On 10/14/2009 18:36, Antonio Diaz Diaz wrote:
> Hello JonY,
>
> Thanks for the packages, and thanks to Tino for his feedback.
>
> I have already uploaded the binary package here (see below about the
> source)
> http://download.savannah.gnu.org/releases-noredirect/lzip/lzip-1.8-win32-1.zip
>
>
> Tomorrow I'll add the link to the home page, so that the mirrors have
> time to catch up.

Thanks!

> JonY wrote:
> > On 10/14/2009 16:03, Tino Lange wrote:
> > > While you're in the mood :-) Do you think that you can port the lzlib
> > > also to win32 / MinGW / MSYS ?
> >
> > OK, I'll take a look at them over the weekends.
>
> Great!
>
> I have just discovered a site maintaining ports of unix tools for
> windows (http://gnuwin32.sourceforge.net/). Perhaps you could take a
> look and get some ideas. Maybe the lzip port could be placed there or in
> a similar site. I don't know.

Placing the lzip source and binaries for gnuwin32 distribution is fine, 
but distributing the binary form of lzlib could be problematic, mostly 
due to compiler ABI issues.

> I am not yet sure what is the best way of distributing modified sources.
> The people at gnuwin32 distributes them as unified diffs
> (http://gnuwin32.sourceforge.net/summary.html).

Distributing unified diffs should be fine, but I'm not sure if there are 
other implications.

> In any case, could you please add a line stating something like "Ported
> to Windows by <your_name>", or "Patched for Windows by <your_name>", or
> "Windows modifications made by <your_name>", (you get the idea), under
> the Copyright line in every file you modified in the source package? I
> think the GPL requires modified versions be marked as such.

I tend to forget how strict GPL is with copyright assignments. Should I 
resend the patches and the source tarball?

> Also I remember a bug report in Debian explaining the file
> share/info/dir should not be included in binary packages. I don't know
> if it matters for windows packages.

Windows itself does not have the info(1) tool, but I'll be sure to 
remove it next time.

> > BTW, I have just been told that signal handlers for CTRL-C and
> > CTRL-BREAK do not work for Windows, the program just ends. I don't
> > think that is will be a huge issue though.
>
> I never expected perfect behaviour of a posix tool on windows.

That is to be expected, Windows doesn't try to be POSIX most of the time 
(unless you use interix/sua/unix subsystem, but thats a different 
issue). The MinGW maintainers are also hesitant about adding additional 
POSIX functions.