Re: Complicated re-distribution of pgjdbc the "open source way"
| От | Craig Ringer |
|---|---|
| Тема | Re: Complicated re-distribution of pgjdbc the "open source way" |
| Дата | |
| Msg-id | CAMsr+YGKR6LnE7DyodNXk5tOJBqhsjsNHJ_Qj56p3kCtNbDVLg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Complicated re-distribution of pgjdbc the "open source way" (Pavel Raiskup <praiskup@redhat.com>) |
| Список | pgsql-jdbc |
On 7 March 2016 at 22:26, Pavel Raiskup <praiskup@redhat.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:
В списке pgsql-jdbc по дате отправления:
Предыдущее
От: Vitalii TymchyshynДата:
Сообщение: Re: Complicated re-distribution of pgjdbc the "open source way"