Re: [HACKERS] Packaging of postgresql-jdbc - Mailing list pgsql-jdbc

On Wednesday 17 of February 2016 16:55:24 Álvaro Hernández Tortosa wrote:
> > 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.

Right, but Vladimir called this "time-bomb", and I mostly agree.  And it
fixes RPM packaging only -> not DEB packaging, archlinux, gentoo, etc., ..
This deserves central place.

>      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.

It is not better solution, just easier -- but as all distros need to do
this, it should be done on one place.  It wouldn't be confusing, there
would definitely be documentation for it.

>      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).

Right, the Fedora's POV is off-topic.  I'm saying it "might not" be safe
for FOSS distribution model to depend on this software.  That is why the
-foss suffix.

> - 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.

It does not seem to be worth the trouble at all, because nobody wants
this.  Distributions probably don't care about osgi.enterprise too much
(== obsoleted packages provided, probably unused, patching out the osgi
support to allow build, etc.), and upstream does not care (for
understandable reasons) to make this soft-dependancy.  Who would be this
additional work for to make the trouble?

>      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?

There are other problems (and we probably don't have all):

- There is the '*-parent-poms' *separate* project, this makes us to make
  the package build done in two phases.  I still don't understand this
  artificial split.

- non-traditional release practices -- we need 'pgdjbc-X.Y.Z.tar.gz'
  file, which clearly describes how to build from source.

- I haven't been able to run the new tests.., which seem to be Travis
  (ubuntu && maven?) oriented

I agree that this could look like expensive effort, but as I said - we do
not want diverge.  Just fix the distribution issues ;).  Nothing more than
what all distributions do anyway with new release, but a consistent way.

Pavel