Bug#809604: [Debian-astro-maintainers] Bug#809604: Regressions in latest uscan release (mangle rules?)

[Osamu Aoki]

Hi,

On Thu, Jan 07, 2016 at 05:31:40PM +0100, Axel Beckert wrote:
> Hi,
> 
> Osamu Aoki wrote:
> > New prioritizing mechanism xz > bz2 > gz > zip by adding sufiix to
> > version as index string is causing this problem.
> 
> Ah, that's the reason for these strange suffixes. Thanks for the
> explanation! :-)
> 
> > > Please also notice the different sorting of 0.9pre6 _behind_ 0.9pre.
> > > It seems as if the new uscan version sorts wrongly if there are two
> > > versions of which one is just a leading substring of the other. Adding
> > > ".1" doesn't seem to make sense to me if the dot is sorted before any
> > > number.
> > 
> > Let me think this over my vacation :-)
> 
> :-)
> 
> > It looks to me adding .+0 .+1 .+2 .+3 instead of .0 .1 .2 .3 seems to
> > avoid this problem.
> 
> I don't think so. Because the first added character is still a dot.
> Adding +0 +1 +2 etc. instead of .0 .1 .2 etc. may work better, but is
> probably not completely sane either.

After sleep and rethink, I was thinking the same and agree with you.
 
> I generally would not try to squeeze suffix preference into the
> version comparison itself, but do the suffix ordering in a separate
> dimension, e.g. first sort by version and if there's more than one
> file for the newest version, then sort them by suffix priority.

But that requires real feature addition to the sorting code and
non-trivial.

Immediate easy workaround is adding +0 +1 +2 etc. instead of .0 .1 .2
which is trivial.  (Or maybe addint +9990 +9991 +9992 to avoid collision
with +1 used by the upstream.)  This is not the perfect solution.  But
this is trivial to do and works for most cases.

Regards,

Osamu
PS: I will be on vac-mode until Jan., 25th. Excuse me for the slow
follow up on this bug.