Re: [HACKERS] Packaging of postgresql-jdbc

Hi Pavel,

I am in the process of creating package torodb (
https://github.com/torodb/torodb) for Fedora (
https://bugzilla.redhat.com/show_bug.cgi?id=1302156) postgresql-jdbc is a
torodb's dependency and, if possible, our goal is to include it in Fedora
22 and above. Actually we are trying to add the postgresql jdbc driver
latest version as a bundle in our package but, as Pavel Raiskup told us,
the right way is to have it stand-alone and depend on it. Since we have
same goal to build the postgresql jdbc driver I decided to kick in and
share my progresses with the community.

For now I just removed waffle dependency patching code (attached) and
removing a couple classes from build:

* org/postgresql/sspi/NTDSAPI.java
* org/postgresql/sspi/NTDSAPIWrapper.java

Actually I am looking into the org.osgi.enterprise artifact dependency that
is missing, as you mentioned, due to incompatible license with Fedora.
After investigating a bit I found out that org.osgi.enterprise library is
shipped with an Apache License (Version 2.0, January 2004) so it is not
clear to me if there are license issues or not. In any case postgresql-jdbc
package use a single interface (org.osgi.service.jdbc.DataSourceFactory)
from artifact org.osgi.enterprise. It would be really trivial to generate a
clean room implementation of the interface and put it in a separate package
or just use for build without installing.

> On 16 February 2016 at 07:50, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
>
>> On 16 February 2016 at 20:15, Pavel Kajaba <pkajaba(at)redhat(dot)com> wrote:
>>
>>> Hello pg-hackers,
>>>
>>> I need advice about postgresql-jdbc driver.
>>>
>>> Current version in Fedora is behind latest version of postgresql-jdbc
>>> (1200 vs 1207).
>>>
>>> We are trying to package latest version into Fedora, but there are
>>> dependencies, which are not useless in Fedora (waffle-jna)
>>
>>
>> Which *are* useless in Fedora. I know that was just an editing mistake.
>> It's a library used in PgJDBC for windows SSPI support.
>>
>> I don't really see the problem here. If your packaging policy prevents
>> you from incorporating it, patch it out. It's use is simple, self-contained
>> and already optional.
>>
>>
>>> and ones which we are not 100% open source (osgi-enterprise). We talked
>>> with upstream quite intensively but not been able to find any solution
>>> which would meet our requirements.
>>>
>>
>> ... which you should probably outline here, because otherwise nobody
>> will understand the problem.
>>
>>
>>> We think that it's not a good, when open-source project depending on
>>> packages, which licence is not 100% clear.
>>>
>>
>> Well, frankly, that's Java. So long as they're soft-dependencies I really
>> don't care.
>>
>>
> I've already explained the JDBC position here.
>
> There is an impedance mismatch between the java ecosystem and distros.
>
> We have moved to maven as have most other java projects.
>
>
> As Craig said, if you want to build it, patch it out, and create a
> ant/Makefile to make the jar.
>
> Dave Cramer
>
> davec(at)postgresintl(dot)com
> www.postgresintl.com
>
>
>