[Bug 815704] [NEW] dpkg-mergechanglogs drops invalid lines

[Andrew Bennetts]

Public bug reported:

Consider this example:

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

  * New upstream release.
  * Awesome bug fixes.

 -- Joe Foo <joe at example.com>  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.

** Affects: dpkg (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to dpkg in Ubuntu.
https://bugs.launchpad.net/bugs/815704

Title:
  dpkg-mergechanglogs drops invalid lines

Status in “dpkg” package in Ubuntu:
  New

Bug description:
  Consider this example:

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

    * New upstream release.
    * Awesome bug fixes.

   -- Joe Foo <joe at example.com>  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/815704/+subscriptions