Re: Complicated re-distribution of pgjdbc the "open source way"

On 7 March 2016 at 22:26, Pavel Raiskup <praiskup(at)redhat(dot)com> wrote:

> _Open_ distribution¹ of pgjdbc is becoming a bit painful for the last
> several releases, mostly because there are some non-free/windows-only
> related _hard_-dependencies (currently osgi.enterprise, waffle-jna) which
> disallow us to build pgjdbc on free distro.
>

They're not particularly hard dependencies, actually. Use is restricted to
a couple of files, by design, and those files can simply be omitted from
the build. You get a runtime error if you try to use JNA in that case, but
if you're on *nix you won't do that.

> The preferred way would be to solve this upstream (making the dependencies
> optional)

... which is perfectly fine, IMO, if done in a maintainable, sensible way.

> but it is not a mandate of pgjdbc upstream to cooperate on this
> -- even patches from us to support pure open source build are not wanted.
>

Not the way you've proposed them so far. That doesn't mean it's not
possible, but your approach so far has IIRC been "break it for everyone
else so it works for us".

> As upstream is not interested in non-maven builds, it will be most
> probably even worse later.
>

Correct. Like most of the Java world. This isn't a PgJDBC problem, this is
a Fedora-Debian-etc-vs-Maven problem. I have some sympathy, as I am aware
of how painful it can be dealing with packaging system mismatches, but I
don't think it makes sense to swim upstream against the whole language
ecosystem to make it more convenient to package a rebuilt driver for Fedora.

There's plenty of precedent with CPAN, the RubyGems network, etc. Usually
painful, but that's partly a consequence of the fact that dpkg and rpm are
designs that are designed first and foremost for C/C++-style shared library
concepts and distribution models.

I use Fedora myself and I like the working(ish) packaging of common Perl
modules on those painful occasions I have to use Perl. I'd like to see
PgJDBC packaged conveniently for users and other packages too. That can be
done with Maven though; Fedora packages Maven its self and numerous
Maven-built packages. Whatever the barriers are here - and I've kind of
lost sight of them now - I'm sure they can be solved without major build
system surgery.

Because PostgreSQL connector is important part of operating system, we are
> thinking about a small friendly fork of pgjdbc, called pgjdbc-foss. This
> should allow us to solve the issue rather sooner than later.
>

I still haven't grasped why you can't just patch the build - in a trivial
and easily maintained way - or add a Maven profile or similar that just
omits the bits you object to.

What you can't do is just patch out the bits you don't like unconditionally
and expect such a patch to get merged.

> * the build would be 1-step process (no need to build pgjdbc-parent-poms
> first, and others), with some obvious system dependencies
>

Huh? It's already a one-step build. Maven builds parent modules.

* build from this tarball must not rely on maven repositories --
> untrusted content at distribution level
>

Fedora has already dealt with that for other packages. You just use a local
maven repo for builds.

* the testsuite should be fixed to allow us to run it easily under
> non-root user, on a local/cloud build-box
>

Huh? How's root currently required? If it is, that should certainly be
fixed upstream.

I'm still convinced you're making this into a much bigger problem than it
needs to be by dismissing approaches that aren't your perfect ideal. You're
not going to get the driver to drop Maven or dependencies you don't like. A
fork is one option, but you could also quite reasonably look at conditional
build profiles.

Start here:

* http://stackoverflow.com/q/6025596/398670
* http://maven.apache.org/guides/introduction/introduction-to-profiles.html

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services