Bug#737843: [uscan] --repack replaces \r\n with \n in text files

[James McCoy]

On Thu, Feb 06, 2014 at 01:30:46PM +0100, Emmanuel Bourg wrote:
> I've got some trouble with uscan when repacking the source zip [1] of
> JavaMail. The file
> 'mail/src/test/resources/javax/mail/internet/folddata' is altered in the
> process. Its md5sum is 7ac9a5 in the source zip, and bbb321 in the
> repacked tarball.
> 
> After investigating it looks like the repacking replaced the \r\n line
> terminators with \n, causing the unit tests to fail.

Daniel requested this in #618513.  I felt a little unsure of it at the
time, but acquiesced.  Given the above effects, and re-reading the
reasoning provided by cryptlib's upstream[0], I'm thinking it may be
best to revert this.

0: To unzip the code under Unix use the -a option to ensure that the
   text files are converted to the Unix format.

I don't see why this requirement is imposed by cryptlib.  If the source
he's distributing uses dos line endings, why shouldn't that be the form
they're modified in?  If someone on a Windows system creates a patch,
their files are going to have dos line endings, not Unix, so I don't
think that suggestion has anything to do with feeding patches back to
upstream.

It's likely just a tip for ensuring the line endings are “correct” for
the user's OS, which, as I stated initially, is less likely to cause
problems for *nix tools if they aren't.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/devscripts-devel/attachments/20140308/59988eb8/attachment.sig>