Hi Jakub, On 29/02/2016 00:27, Jakub Wilk wrote: > * Giulio Paci <giuliop...@gmail.com>, 2016-02-28, 23:19: >> I packaged >> "http://openfst.org/twiki/bin/viewfile/FST/FstDownload?filename=openfst-1.5.1.tar.gz;rev=1" >> and noticed the behaviour when upstream was at >> "http://openfst.org/twiki/bin/viewfile/FST/FstDownload?filename=openfst-1.5.1.tar.gz;rev=3". >> Right now they are at >> "http://openfst.org/twiki/bin/viewfile/FST/FstDownload?filename=openfst-1.5.1.tar.gz;rev=8". >> I still did not check the last revision. >> I have not found any reasonable way to detect when the package changes. >> Essentially the algorythm should be: check for latest version of the >> package, if the same package >> exist with rev=<something>, then the package is at the "same version" + >> revision <something>+1. >> >> Given the current situation, do you think I should upgrade the upstream >> files in pristine-tar? >> Should I have different versioning with respect to upstream or should I >> maintain the same version scheme even if several versions collapse into the >> same version? > > Hmm. With pagemangle (available in devscripts >= 2.15.10) we could probably > teach uscan about different revisions of the same file. But that'd be > probably very brittle... > > So how about asking uscan to always download revision 1? This should be > straight-forward: > > opts="downloadurlmangle=s!.*/FstDownload/(.+)!http://openfst.org/twiki/bin/viewfile/FST/FstDownload?filename=$1&rev=1!" > > (I had to use "&" instead of ";", because you can't use semicolons in mangle > rules. I hate uscan.)
Today I checked the differences between rev 8 and current packaged version... And they are not just minor changes as it happened before, they also changed ABI, without changing SONAME (again :-(). I think: 1) I need to package latest version, as the differences are not trivial anymore; 2) I have to convince upstream stop these bad practices (however it seems very hard, as they stop for one release and then start again a immediately after); 3) *mangle mechanism seems not enough in this case as we need some math (we have to compute "<something>+1") and the math has to be applied to a value that is not the current one (we have to check that /twiki/bin/viewfile/FST/FstDownload?filename=openfst-1.5.1.tar.gz;rev=<something> exist, in order to compute <something>+1 on http://www.openfst.org/twiki/pub/FST/FstDownload/openfst-1.5.1.tar.gz). I am going to write to upstream again. In the meanwhile, do you think I can package openfst-1.5.1.tar.gz rev 8 under openfst-1.5.1.tar.gz name? Bests, Giulio