[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#570064: diffutils 2.9 breaks dpkg-dev



Hello.

The recent diffutils 2.9 release, which I've uploaded for Debian
unstable, breaks dpkg-dev in a very bad way.

Raphael Hertzog, dpkg developer, has analyzed this issue. What follows
is an abridged version of a previous mail, this time sent to the
preferred address for diffutils bugs.

The source for the breakage is in this commit:

http://git.savannah.gnu.org/cgit/diffutils.git/commit/?id=a352f09806a8606b4bbec07048da6762ce7d9afa

In Raphael's words:

 dpkg-source has been relying this specific output of diff
 since its inception (in the nineties) and I really don't agree with the
 justification of the upstream change. We need a way as users to know
 that one of the file contains binary data, saying "Files differs"
 would lead me to ask myself "but then why don't you show me the difference??".
 The binary indication was fine.

 BTW, Dan Jacobson is known to submit lots of discutable bug reports
 on cosmetic details... but here the impact is much more than cosmetic.
 Paul or Jim, can you revert this change on the uptream side?

 [...]

 Questions for the diff upstream maintainers: what's the best way to call
 diff to detect if diff considers a file as binary?

 Can we rely on "File /dev/null and bar differ" to mean that bar is a
 binary file?


Note: I also would like the change to be reverted.

While it's true that "binary files foo and bar differ" is not
completely true when one of the files is binary and the other is not,
if such message is changed to just "files foo and bar differ" then
there is clearly a loss of information.

Previoulsy, the real meaning of "binary files foo and bar differ" was
really "the files differ, at least one of them is binary so I'm not
showing you the diff".

I would suggest that this clarification is put in the manual instead of
changing the program output.

Alternatively, if the program output needs to be changed, I would suggest
that it's done in a way that does not produce loss of information.

Thanks.


Reply to: