Re: [HACKERS] Packaging of postgresql-jdbc

     Hi list!

On 17/02/16 12:43, Pavel Raiskup wrote:
> Hi Matteo,
>
> On Wednesday 17 of February 2016 10:39:43 Matteo Melli wrote:
>> 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.
> this is certainly an issue and we have already written similar patches
> you've proposed.  Thanks for your work!  As this issue is not "just" about
> Fedora, but it rather hurts all GNU/Linux distributions - let's discuss
> how to do it a consistent way...

     Absolutely.

>
>> 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
> Yeah, that is something which should be optional.  As this is not easy, we
> should patch it out.

     So I believe this is a simple, good solution. The problem with
waffle is how to "remove" it without asking upstream to change it. Well,
what Matteo did is simply patch it but as part of the spec to build the
src.rpm. This patch is very simple and makes it buildable as an RPM
without asking upstream to make any changes to the code. Thus I think
this fixes this problem.

>
>> 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.
> AFAIU, osgi.enterprise refuses you to modify it's code.  That requirement
> makes it incompatible with Fedora and all open source re-distributors
> (vendor-lock-in).
>
> I'm not sure what are the issues with GPL license compatibility .. IANAL,
> but IMO you can use MIT/BSD libraries from GPL licensed project, but then
> you have to distribute your whole work as GPL code -- which is not a
> problem per se, but GPL *enforces* you to keep the code modifiable, while
> osgi.enterprise refuses this;  this sounds like a clear collision.
> However, we agreed this is not an issue for pgjdbc project and thus no
> need to complicate upstream maintenance.  There was long discussion .. and
> probably nothing more to add.
>
> So -- patching out osgi.enterprise support would work for us similarly to
> waffle.  And possibly in future; make the 'osgi.enterprise' support in
> separate jar file with clear license clarification would work too..
>
> ---
>
> People mostly (including pgjdbc upstream maintainers) suggest us to patch
> the unclear stuff out from pgjdbc code .. which is pain to do over and
> over again in all distributions.  We are considering a "close" fork of
> pgjdbc (say 'pgjdbc-foss').  That fork should allow us all to package the
> jdbc plugin "consistent" FOSS way.  There is no point in duplicating the
> maintenance effort -- pgjdbc upstream does a good job here -- so we would
> be in sync with pgjdbc and concentrating just on the distribution POV;
> doing just the necessary changes.
>
> I'm going to write a separate mail into new trhead to this list (with CC
> to package maintainers in other distros) with ideas, requirements, etc.
> But any idea from anyone here is welcome.
>
> Thanks, Pavel

     I think that creating and maintaining a pgjdbc-foss is both time
consuming and potentially confusing for end users. I believe what Matteo
was suggesting is a probably better solution and it's definitely KISS.

     Summarizing Matteo's suggestion:

- osgi.enterprise is not allowed in Fedora (and it seems futile to me to
discuss whether this is right or wrong).

- Apache Felix, which is already packaged for Fedora, provides almost
all the code needed for OSGI support in pgjdbc

- Only 1 interface is not provided by Felix. Rather than looking for
someone else to provide this interface, we should just re-implement it
(it's just a few lines of code!). It could be done as a clean-room
implementation to avoid actually copying the code. This interface could
either be added to pgjdbc or to a side repo (something like
pgjdbc-osgi-compatibility or any other similar name) and setup a
dependency on this trivial project.


     With the above recipe, pgjdbc should also be buildable as an RPM,
without modifying upstream code. I believe no other problems would be
left for packaging it. What do you think?


     Cheers,

     Álvaro


--
Álvaro Hernández Tortosa


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