[Pkg-virtuoso-maintainers] Rebuildability of various binaries and shipped libraries for Debian packaging

[Obey Arthur Liu]

Hi,

I'm continuing the work on various aspects of the debian virtuoso
packages and I have a few new issues I'd need your help on.
The following refers to the 20091210 6.0.1-rc1 tarball.

PCRE
====
libsrc/util/pcrelib/
Virtuoso ships and links to a modified version of PCRE 7.9 (with some
additional debugging features). I tested it and vanilla PCRE 7.8 (the
most recent version in Debian) works fine. Could you add a build
option to use the system version instead, like you did for zlib?

Tidy
====
libsrc/Tidy
Virtuoso ships, links to and re-exports an obsolete version of the
Tidy library. There seems to be some switchable code to accommodate
the different API of the newer Tidy but since its interface is
re-exported, the switch doesn't seem that simple. Can you look into
this? While Tidy seems to be less security-critical than zlib or pcre,
it's always better to rely on system libraries.

Tutorial VAD
============
binsrc/tutorial
The tutorial VAD ships numerous pre-built mono .dlls that can't be
rebuilt (or I haven't figured out how). How can I rebuild them from
source ? The .net virtuoso client in binsrc/VirtuosoClient.Net builds
fine with mono.

All JARs
========
*.jar
Virtuoso ships numerous pre-built java .jars built on source that is
not included in the tarball. README.sesame2/3 and README.jena explain
that the user has to get them manually. Because they are BSD-licensed,
you are allowed to do this but this won't work for the Debian archive.
Could you look into the possibility of using system installed versions
of sesame, jena, slf4j... directly into the build system? Otherwise
I'll have to patch one into the source code and I'll rather have you
decide how you prefer to do it.
Note that sesame and jena are not in Debian yet (but slf4j is, so you
can try it with that) but I'm considering packaging them.

Parallel building
=================
I still have trouble with parallel building (make -j). It works better
now, but still not all the time. I attached a patch
(build-generated-code-multiple-outputs.patch) that solves one point of
failure for me, there are still many more.

Use of gmake
============
There are a few uses of 'gmake' in makefiles. gmake is not present in
Debian. $(MAKE) should be used instead.

That's all for now.

Cheers

Arthur