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. _______________________________________________ devscripts-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/devscripts-devel
