Complicated re-distribution of pgjdbc the "open source way" - Mailing list pgsql-jdbc
From | Pavel Raiskup |
---|---|
Subject | Complicated re-distribution of pgjdbc the "open source way" |
Date | |
Msg-id | 2562462.qBr8q3cvoq@nb.usersys.redhat.com Whole thread Raw |
Responses |
Re: Complicated re-distribution of pgjdbc the "open source way"
Re: Complicated re-distribution of pgjdbc the "open source way" Re: Complicated re-distribution of pgjdbc the "open source way" Re: Complicated re-distribution of pgjdbc the "open source way" Re: Complicated re-distribution of pgjdbc the "open source way" Re: Complicated re-distribution of pgjdbc the "open sourceway" Re: Complicated re-distribution of pgjdbc the "open source way" Re: Complicated re-distribution of pgjdbc the "open source way" |
List | pgsql-jdbc |
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
pgsql-jdbc by date: