[Bug 815704] Re: dpkg-mergechanglogs drops invalid lines

[Raphaël 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.

** Changed in: dpkg (Ubuntu)
   Importance: Undecided => Low

** Changed in: dpkg (Ubuntu)
       Status: New => Confirmed

-- 
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:
  Confirmed

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