Re: [HACKERS] Packaging of postgresql-jdbc

On Wednesday 17 of February 2016 18:25:30 Álvaro Hernández Tortosa wrote:
> > 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?

Because the patch might start to not apply in future, and all the
distributions need to start re-patching...

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

I believe this has been discussed before, and Pavel Kajaba already worked
on it .. but this is not acceptable by upstream.

> So why not, rather than searching for the perfect solution, take a
> simpler one and then iterate?

Don't take me wrong -- it is easier to do the patching your way, but on
one place!  Then take the tarball and you are done.

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

Well, how exactly you expect this patch to be applied?  Because deb
maintainers usually do not watch RPM packaging and vice versa.

> >>       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! :)

Again, KISS and DRY principles.

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

Agreed here.

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

Right, but you need to do the contribution somewhere.  This is not about
RPMs only.

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

Exactly, but not possible ATM if we pay attention to foss principles.

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

End users would be able to use 'pgdjbc-foss' or 'pgjdbc-foss-osgi' (KISS).

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

Oh, I see what you mean :) now -- but those licensing issues should be
fixed upstream..

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

I still don't get the reason why there can't be single one tarball.  It is
a problem, every distro is going to build the package in two-steps.
Gentoo guys do build their packages themselves!

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

I was able to do this too.  But having a fork will make this easy for
everyone (DRY).

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

No-no-no :).  Ideally¹ we should be able to (a) run the testsuite during
package build (no root access, no network access) in cloud, and (b) we
should be able to package the testsuite for user -- so anyone is able to
run the testsuite on end-user box.  This sounds like sci-fi now, but it is
really important to run the testsuite at least during package build.

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

Right, thats why I do not plant to do anything expensive!  Just
accumulate the things at one place -- the things which upstream forces us
to do on per-distribution level.

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

It works.

¹ This has been don for postgresql.spec (server).  But with pgjdbc we are
  even unable to *build* from source :).

Pavel