Bug#819170: uscan --dehs element nesting messed up for multi-line watch files

[Harald Sitter]

Package: devscripts

In packaging for KDE software we have wach files like these:

> version=3
> http://download.kde.org/unstable/plasma/([\d.]+)/libksysguard-([\d.]+)\.tar\.xz
> http://download.kde.org/stable/plasma/([\d.]+)/libksysguard-([\d.]+)\.tar\.xz

i.e. with more than one match rule

Running uscan --report-status --dehs on such a watch file will attempt
to create 2 package elements in the dehs output and fail miserably. It
will simply print all relevant elements twice as a matter of fact,
which makes no sense as XML documents are not meant to impose order.

> <dehs>
> <package>libksysguard</package>
> <debian-uversion>5.6.0</debian-uversion>
> <debian-mangled-uversion>5.6.0</debian-mangled-uversion>
> <upstream-version>5.5.95</upstream-version>
> <upstream-url>http://download.kde.org/unstable/plasma/5.5.95/libksysguard-5.5.95.tar.xz</upstream-url>
> <status>Debian version newer than remote site</status>
> <package>libksysguard</package>
> <debian-uversion>5.6.0</debian-uversion>
> <debian-mangled-uversion>5.6.0</debian-mangled-uversion>
> <upstream-version>5.6.0</upstream-version>
> <upstream-url>http://download.kde.org/stable/plasma/5.6.0/libksysguard-5.6.0.tar.xz</upstream-url>
> <status>up to date</status>
> </dehs>

Notably if I were to parse this top-down the upstream-url would be
> http://download.kde.org/stable/plasma/5.6.0/libksysguard-5.6.0.tar.xz
while if I were to parse it down-top it would be
> http://download.kde.org/unstable/plasma/5.5.95/libksysguard-5.5.95.tar.xz
If one were to process the elements in threads super fun time begins.

Possibly solutions would be to pass the name via attribute, this would
however break most existing parsing.
<package name="libksysguard">
  <debian-uversion>...
</package>

The other probably more backwards compatible approach is to create two
dehs elements
<dehs>
  <package...
</dehs>
<dehs>
  <package...
</dehs>