Hi James-- Thanks for the prompt followup.
On 03/15/2011 10:50 PM, James Vega wrote:
> This relies on zip properly identifying files as text/binary, which it
> may not do perfectly, as the man page calls out.
Note that zip is not the only tool that upstreams use to build a pkzip
archive.
My experience is that pkzip archivers tend to err on the side of storing
text files as binary (in which case this fix wouldn't make a
difference), not identifying binary files as text (in which case this
fix would actively hurt, as you say).
(and of course, when the archiver doesn't err at all, passing -a is
clearly the right thing to do)
> I'd wager that *nix
> tools are pretty good at handling non-native line endings (at least
> better than my experience with Windows tools), so is it necessary to do
> the conversion? Have you run into issues with CR/LF line ending files
> that prompted this patch?
sure. as i mentioned, i'm looking at peter gutmann's cryptlib. His
manual [0] says:
To unzip the code under Unix use the -a option to ensure that
the text files are converted to the Unix format.
If i decompress the archive as upstream expects, and create a diff
against it, that diff will not apply properly against a tarball repacked
by the current incarnation of uscan.
So i'm faced with the choice of:
0) not using uscan's repacked tarballs, or
1) distributing patches that don't apply to properly-unpacked upstream
source.
Does this make sense?
--dkg
[0] http://www.cryptlib.com/downloads/manual.pdf
signature.asc
Description: OpenPGP digital signature
