Re: RFS: VLFeat computer vision library
Hi
Andreas Tille <andreas@an3as.eu> writes:
> I checked this out and have noticed in debian/README.source:
>
> "The SIFT implementation was removed from the source ..."
>
> That's OK, but if you change the upstream source you should either
> provide
>
> a) get-orig-source target in d/rules
> b) specify Files-Excluded in d/copyright and use the enhanced
> uscan described here:
>
> https://wiki.debian.org/UscanEnhancements
>
> I personally recommend the latter since it is more simple to implement
> and from my personal point of view more transparent.
That wiki page isn't 100% clear. Is the goal to generate the +dfsg
source tarballs in a more standardized way?
I have a single commit in git that does this stripping, and I intended
to rebase this commit on top of every new release. This commit does more
than just delete some files: it also tweaks some of the documentation
and demos to not try to run or describe in detail the removed code.
Are you suggesting adding Files-Excluded to d/copyright and then using
the patched uscan from here:
http://anonscm.debian.org/gitweb/?p=users/tille/devscripts.git;a=summary
Is this modified uscan going to be included into the main archive at
some point? Also, this approach would only delete some files, not modify
the docs, demos and build. I can do that in a debian/patches/... Is that
what you are suggesting?
>> > In what Debian Science task would this library fit best?
>>
>> The "image analysis" task sounds most appropriate to me.
>
> I added
>
> Suggests: libvlfeat-dev
>
> since we usually link to user applications in non-dev metapackages. It might
> make sense to consider an imageanalysis-dev metapackage since the task now
> is assembling several lib*-dev packages that way. What do you think?
I'm not too familiar with the intended use cases for these packages. If
these are all meant for developers, then putting the lib*-dev into the
non-dev metapackages is fine by me. But if science-imageanalysis is
intended for end users, then a separate science-imageanalysis-dev
certainly makes sense to hold the libraries.
> Is there any chance to also create a vlfeat-{tools,utils} package with a
> plain user application for demonstarting the library?
The upstream ships two utilities, one of them demonstrating the non-DFSG
SIFT functionality. So the vlfeat-tools would have just the one
remaining program. There's some testing code in there as well, but it's
not useful for an end user to run. Is it worth it to make vlfeat-tools
to just contain that one utility? I don't ship it at all right now, so
perhaps it is worth it.
> Feel free to add your package to the SoB Wiki page.
Sorry, what's SoB?
dima
Reply to: