Bug#814852: RFS: openfst/1.5.1-1 -- weighted finite-state transducers library

[Giulio Paci <giuliopaci@gmail.com>]

Hi Jakub,

On 27/02/2016 19:04, Jakub Wilk wrote:
> [When filing a bug, please use X-Debbugs-CC instead of plain CC, so that the copied person receives the message with bug number from the BTS.]

Thank you for the hint. I will do that next time.

> * Giulio Paci <giuliopaci@gmail.com>, 2016-02-16, 01:03:
>> https://anonscm.debian.org/git/collab-maint/openfst.git
> 
> I had only a very quick look at the package so far:
> 
>> * Drop 1001, 1002, 1003.
>> * Avoid 2001 patch usage.
> 
> Someone who's not familiar with the package history would have no idea what this means. Please be more verbose here.

I added full patch names and reported that "2001" patch is no more needed.

> Do you plan to forward unresolved-symbols.diff upstream?

Actually I already did it (several times).
I updated the patch header accordingly.

> Typo in README.Debian:
> binaries depends -> binaries depend
> 
> Typos in fstlinear.1 and fstloglinearapply.1:
> chracter -> character

I fixed those typos.

> The tarball uscan downloads is different that the one pristine-tar generates:
> 
> $ md5sum openfst_1.5.1.orig.tar.gz.*
> 9b6e9a5042b986919f62c5184e3e352d  openfst_1.5.1.orig.tar.gz.pristine-tar
> 8869e44c5a4af65409ae78b9f482b40e  openfst_1.5.1.orig.tar.gz.uscan
> 
> Do you know how did that happen?

Yes, I know. Upstream uploaded more than one tarball with minimal changes fixing minor issues.
I already talked about this issue with upstream and about the implications. But still I do not know about their decision on this subject.
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?

Bests,
	Giulio