Bug#684220: RFS: tinysvm/0.09-1 [ITP] -- SVM trainer and classifier toolkit

[Jakub Wilk <jwilk@debian.org>]

* Giulio Paci <giuliopaci@gmail.com>, 2012-10-27, 18:28:
> > > I finally decided to repackage the tarball with files generated by 
> > > more recent versions of swig.
> > > I used an interface file downloaded from 
> > > https://github.com/shogo82148/TinySVM/.
> > The binding should be regenerated at build time. But... are they 
> > currently used at all? If not, it might be simpler just to strip them 
> > out completely.
> I do not know any user of the bindings, but I would prefer to keep at 
> least their sources in the package (I have to repackage the tarball 
> anyway and the bindings sources do not introduce a large overhead), if 
> it is not a problem to leave the source there and not compiling them.

If the idea is to leave out all the generated files, but keep the SWIG 
interface file, then yes, it should be fine.

> > In any case, please provide a get-orig-source target.
> I have no experience with this target.

Very well! That means you'll learn something new. ;)

> I read the description on this page 
> (http://www.debian.org/doc/debian-policy/ch-source.html), but I did not 
> understood what I am supposed to do.
> As far as I understood, this target should provide a way to get the 
> sources for the patched upstream tarball.
> Anyway the description reports that the target should:
> 1) download the original source file;
> 2) recreate the patched source;
> 3) tar the patched source.
>
> It is possible to implement these steps, but I need some software to do 
> that (e.g., something to retrieve files from upstream and from 
> https://github.com/shogo82148/TinySVM/ and the same version of swig 
> that I used to recreate the bindings file).
> How should I handle these additional dependencies?

There's no standardized way to declare which packages are needed for 
get-orig-source. This is not a problem in practice, as this target is 
run only by humans, who are usually smart enough to figure out what's 
needed. :) As long as you use tools that a typical developer is more or 
less familiar with, you should be fine.

> On the other hand I am storing the tarball in a git repository using 
> pristine-tar, so it would be easier to get files from git and 
> pristine-tar (I just need to publish the git repository somewhere).
> Can I rely on git and pristine-tar to implement this target (this will 
> provide patched sources in a more reliable way)?

That would be cheating, sorry. :P

> I guess that the three steps above are suggested because they suppose 
> that newer versions of the upstream tarball will continue to pose the 
> same problem. Are those three steps mandatory?

Re get-orig-source, it is not not required by Policy.

However, _I_ do require from packages I sponsor that I can recreate 
.orig.tar, either semi-automatically or at the very least using only 
documentation included in the source package. That is:
- either .orig.tar can be downloaded with uscan;
- or get-orig-source exist;
- or README.source explaining how to recreate .orig.tar exist (see 
Policy §4.14, point 4).

--
Jakub Wilk