Re: Complicated re-distribution of pgjdbc the "open sourceway" - Mailing list pgsql-jdbc

     Hi Pavel.

     As you are well aware :) we (as in 8Kdata) are packaging ToroDB,
java software that relies on pgjdbc. Since we saw that this issue was
not moving forward, we investigated the issue on our own.

     While as of today the current ToroDB spec that we have is depending
on an older version of JDBC --which is highly undesirable-- we have also
built a simple mean of packaging pgjdbc for Fedora without having to
modify upstream.

     Since RPM packages allow (and some of them heavily use) patches
against upstream, this is easy to accomplish. Having a parent pom is
neither a problem --it is packaged as a subpackage (might not be ideal,
but hey, it works, and it doesn't harm). All in all, with all the
obvious advantages and disadvantages, we have working source code.
Rather than a will to patch upstream or fork pgjdbc, we have a working
spec that packages pgjdbc, removing (by patching) all the non-foss and
windows dependencies and code, and packaging the parent pom too.

     I believe iterating over this effort is better than either forking
or patching upstream.

     I don't have the code, but Matteo (cc'ed), who did this work, will
share it tomorrow.

     I'd suggest to work on this, which seems to me as a compromise
solution, and agree all on this solution, rather than plan longer-term
plans that, while ideal for some, aren't for the rest and, and above
all, will take significantly more effort. Our main goal is to deliver
packaged and foss pgjdbc to the users asap, and here we have an already
working solution.

     Matteo, please share the code whenever possible.

     Cheers,

     Álvaro

--
Álvaro Hernández Tortosa


-----------
8Kdata




On 07/03/16 15:26, Pavel Raiskup wrote:
> Hi all,
>
> --
> I'm taking the liberty of CCing all pgjdbc packagers I'm aware of (please
> opt-out if you don't care and sorry for rush).  I just want to see whether
> we in Fedora are thinking a constructive way.  This is not GNU/Linux
> oriented effort, but it is rather about any open source
> packagers/distributors, feel free to add anybody who might be interested
> in the loop.
> --
>
> _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.
>
> The preferred way would be to solve this upstream (making the dependencies
> optional), 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.
> As upstream is not interested in non-maven builds, it will be most
> probably even worse later.
>
> We've done some small observation around GNU/Linux packages, and it seems
> we all reinvent the very similar patches or hacks over and over again.
>
> 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.
>
> That project idea:
>
>    * we should provide an _easy to use_ (documented how to build from
>      source) version-ed tarball, compatible with pgjdbc
>
>    * this tarball would be FOSS source-only, with FOSS dependencies,
>      (non-free deps could be possible in future, but only as opt-in
>      feature)
>
>    * the build would be 1-step process (no need to build pgjdbc-parent-poms
>      first, and others), with some obvious system dependencies
>
>    * that tarball would allow us to 100% build-from-source _without_ tweaks
>
>    * build from this tarball must not rely on maven repositories --
>      untrusted content at distribution level
>
>    * the testsuite should be fixed to allow us to run it easily under
>      non-root user, on a local/cloud build-box
>
> Would you be interested in having one common code-base for
> open-source-distribution-model of pgjdbc, and optionally (preferably)
> cooperate?  That source should be as close as possible to pgjdbc, just
> limited limited set of patches to allow us to build/test/distribute
> correctly and what is more important we could do the job _consistently_
> with a lot _less_ packagers effort.
>
> Just let me know if this is good/bad idea from your packackar's POV.  Some
> links for discussion with upstream about issues [1,..N].
>
> ¹ By that I mean ability to build from FOSS source, _against_
>    FOSS source dependencies.  By FOSS source I mean software which
>    _anybody_ can read, study, copy, modify, distribute.
>
> [1] http://www.postgresql.org/message-id/1831842355.39585708.1455624950515.JavaMail.zimbra@redhat.com
> [2] http://www.postgresql.org/message-id/2113338928.20942725.1448530160996.JavaMail.zimbra@redhat.com
> [3] http://www.postgresql.org/message-id/5479464.pnS2mdyLUu@nb.usersys.redhat.com
> [4] http://www.postgresql.org/message-id/2217774.p6G2ev8LQ6@nb.usersys.redhat.com
>
> Pavel
>
>
>