dpkg-mergechanglogs drops invalid lines

[Andrew Bennetts]

Consider this example:

{{{
$ cat orig.changelog
psuedo-prog (1.1.1-2) unstable; urgency=low

  * New upstream release.
  * Awesome bug fixes.

 -- Joe Foo <email address hidden> Thu, 28 Jan 2010 10:45:44 +0000

$ cat invalid.changelog
psuedo-prog (1.1.1-2) unstable; urgency=low

  * New upstream release.
  * Awesome bug fixes.

 -- Thu, 28 Jan 2010 10:45:44 +0000

$ dpkg-mergechangelogs orig.changelog invalid.changelog orig.changelog 2> warnings.log
psuedo-prog (1.1.1-2) unstable; urgency=low

  * New upstream release.
  * Awesome bug fixes.
$ echo $?
0
}}}

Notice how the invalid line (the line with the datestamp lacks an author, which is required) is just dropped from the output. To be fair, the tool does emit a warning about the invalid line:

{{{
$ cat warnings.log
dpkg-mergechangelogs: warning: invalid.changelog(l6): badly formatted trailer line
LINE: -- Thu, 28 Jan 2010 10:45:44 +0000
dpkg-mergechangelogs: warning: invalid.changelog(l7): found eof where expected more change data or trailer
}}}

But I think it's more surprising to the user to drop this line than preserve it. At least in this case dropping the line makes the output even less well-formed than it would be if it were preserved.

Another issue is it may be hard to figure out how the line numbers in warnings correspond to the final output, making it hard for the user to correct the output. (I suppose they could instead try correcting the input and redoing the merge, but that might be a little awkward if the invalid data is sourced from someone else's branch in a VCS.) If the wrong line were still intact in the output it this would be less of an issue.

(I can see a counter-argument that sometimes the final merge might look quite different if run on well-formed inputs, so perhaps insisting that the inputs are corrected is the right thing to do? But in this simple example at least that's not the case.)

Because the tool does clearly warn about the badly formatted input, this doesn't seem very important, but it does complicate some automated test cases for bzr-builddeb.

[Raphaël Hertzog (hertzog)]

FWIW, this is a documented limitation, you can check the manual page. Given the way the code is structured, it's unlikely to be fixed any time soon.