Catch upgrade, preferred form for making modifications

[kapouer]

This is mainly about redistributability of the embedded copy of Catch
in the test suite. For example debian policy requires source code to
be distributed in its "preferred form for making modifications".

I took the opportunity to upgrade Catch to version 1.0 build 8, which
required some relatively obvious changes and one patch for Catch,
see catchorg/Catch2#195.

[springmeyer]

Thanks for helping upgrade catch. As far as distributing catch in its non amalgamated form, wouldn't that make sense only for a catch .deb itself. Why would a test framework need to be modified?

Also, in general are you thinking of packaging mapnik-vector-tile as a .deb? If so can you explain why? I would prefer this not be packaged. It should rather be considered to be part of node-mapnik.

[kapouer]

The single file catch.hpp can be indeed rebuilt from source when there is a catch.deb.
I postponed packaging Catch just because it looked to be near a 1.0 release (and also
it needed to be patched to compile).

I'm an early adopter of your great work on vector tiles, so the idea was to
package an up-to-date mapnik/tilelive stack. Debian is currently at the start
of a new release cycle, so there will be plenty of time before those packages
hit next stable release.
I understand mapnik-vector-tile is bound to be used only by node-mapnik,
and suppose you had a reason to externalize it. If that's the case, it is
perfectly all right to build node-mapnik deb out of multiple source tarballs,
that are node-mapnik.tar.gz + mapnik-vector-tile.tar.gz.

[kapouer]

• catch debian package uploaded

[kapouer]

• kept single file catch

[springmeyer]

node-mapnik deb out of multiple source tarballs, that are node-mapnik.tar.gz + mapnik-vector-tile.tar.gz.

That would be excellent. The idea of the repo being external on github is so that it can have its own test suite and because this code is a candidate for inclusion in mapnik core at some point. But as I said, and as it sounds like you understand, currently this code should functionally be considered sources of node-mapnik only (or sources of whatever app uses it - in the future I plan standalone python bindings). So I really do not want the situation where this repo is it own .deb because that would be very hard to keep in sync. Right now its dead easy to keep in sync because of the way npm/package.json works but I can't imagine that working as well with .debs.

Anyway, thanks for packaging mapnik and node-mapnik in debian, which is awesome.