Re: [HACKERS] Packaging of postgresql-jdbc

On 17/02/16 17:47, Pavel Raiskup wrote:
> 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.

Why would it be a time-bomb?

While I'd agree a better solution is to work around pgjdbc's code
to circumvent waffle on non-Windows systems, I see this could take long,
it's non trivial and I don't see anyone working on it (please correct me
if I'm wrong). So why not, rather than searching for the perfect
solution, take a simpler one and then iterate?

Other distros will surely benefit anyway, as the process of
patching a source rpm/deb/whatever only differs in implementation
details (how you do it), not on the concept of doing it.

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

Well, that's already probably better: KISS! :)

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

I'd take this one step at a time. Let's package for Fedora, next
when others ask, we will provide the answer: do this patching and blah
blah blah, done :)

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

The trouble is just some hours of work, and we're (8Kdata) willing
to contribute those, no problem.

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

I think we should let the users choose whether they care or not.
This is a functionality of the driver, and removing it is removing
functionality from the driver. And upstream seems not to be very happy
with this.

We definitely don't know how much or less users use this, but
removing something that works and might be used is what may cause
trouble. Specially, if it is just a few hours of work away to fix the
licensing issue.

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

It is done to help make versions of the driver for different
versions of the JRE without duplicating a lot of code. Whatever it is,
it is not a big problem, and I believe this is nowadays non-negotiable
for upstream. Again, at 8Kdata we have been able to work around this
easily and can provide a spec that handles this :)

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

Again this can be easily fixed in the spec. There are of course
versioned tar.gz on Github: https://github.com/pgjdbc/pgjdbc/releases

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

I think running tests is cool for the packaging process, but is
this needed for packaging? I mean, it's upstream who should run them
before releasing versions, right? :)

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

It's not easy to package Maven-based software, as there is some
overlapping in the concept but with different point of view. I won't
further look into expensive efforts. There are few resources and we'd
better direct them to other areas.

If the proposed solution works, and it's simple, why not just
simply go for it?

Cheers,

Álvaro

--
Álvaro Hernández Tortosa

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