* Giulio Paci <giuliopaci@gmail.com>, 2013-02-01, 00:03:
You are right, however upstream never provided shared libraries, we are still API compatible with upstream and the patch has been included upstream. Can we break ABI in this case? Should we wait the first shared library released from upstream instead?To improve the manpages I improved the command line help messages (1008_improve_command_line_help.patch)Doesn't this patch break ABI?
Normally, you should avoid ABI-breaking patches even if they've been accepted upstream. If there's no other option than to break ABI between upstream releases, you should release Debian package with Debian-specific SONAME.
But given that it's the first release (thus there are no reverse dependencies), and we upload to experimental anyway, I think we can get away with it this time.
Speaking of which, I had a look at the list of exported symbols, and it's kinda messy... Some symbols have very generic names. Upstream should consider putting them into a namespace.I think I can work on this and have it included upstream.
Great.
I would be surprised if decompression worked correctly, though I don't have access to a Windows system to test it.1007_escape_filename.patchThe latter fixes .bz2 handling and should work on Windows as well (although I have not tested it yet on a real Windows system)."^" is a cmd.exe escape character, but then the executed program does argument parsing on its own. It's usually done by the MSVC++ runtime:http://msdn.microsoft.com/en-us/library/ms880421.aspxYou are right, in fact I first implemented the command line parsing escape. Then I realized that I also needed cmd.exe escape. Then I guessed that I only needed cmd.exe escape as ">" and "<" are breaking the command line.
That is correct for compression, but (unless I'm missing something) there is no "<" or ">" in the _decompression_ commandlines.
-- Jakub Wilk