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

[Osamu Aoki]

Hi,

On Thu, Mar 24, 2016 at 01:20:13PM +0100, Harald Sitter wrote:
> 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

... expecting both rules are evaluated and the newest is identified.
Right now, human needs to pick one out of two.  I knew KDE people are
doing this but is this documented uscan feature and is this how uscan
should work.  DEHS issue needs to be addressed after deciding how should
we best handle KDE like situation.

> 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.

I was aware of this problem.  When I was reorganizing uscan, I almost
wish to make such rule to be error or just use the first rule only.

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

??? I do not get this.

My thought was more like ...
<dehs>
<rule id="1">
<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>
</rule>
<rule id="2">
<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>
</rule>

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

Oh... was that what used to be ...

This can be easily done but before changing things, let's think a bit
more...