Re: [HACKERS] Packaging of postgresql-jdbc

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

     The patch is a very very simple one. It's not much more than "under
this XML Path, remove this XML node (the maven dependency)". While it
may break at some point (well, that's what happens when you patch
upstream), but it's unlikely.

     The only other real alternative is change the code to work around
waffle, and after a long time debating I have seen nobody to come up
with a fix for this.

     So I'd rather move forward even if the solution is not ideal...

     or is there any other *already working, not theoretically*
alternative? My main point is: please, GTD! :)


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

     Yeah, so we have to work around it. That's why we are suggesting
this alternative.

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

     If I understood it correctly, the RPM specs specifically allow (and
I believe is common place) to patch upstream software, to adapt it to
the specificities of RPM packaging. I believe this patch perfectly
belongs to this category.
Good news is that to do this, we don't need any upstream approval :)

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

     Well, when Debian maintainers would ask pgjdcb, the same way as you
did, we will point them to the solution applied to the RPM, which will
be already working, so that they could apply the same technique
--shouldn't be hard.

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

     We both agree :) But forking pgjdbc to create pgjdbc-foss is, to
me, much more DRY than a tiny patch that might be distribution-dependant.

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

     We can do this contribution on our own repos, and send a PR to
pgjdbc. This is not hard, we can do it in <24h.

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

     I care a lot about FOSS principles, and that's the main reason if
we rewrite the interfaces, they will be completely FOSS.

>
>> 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).
     I think this will make users nuts. There will be three versions of
the driver:

- One in the official website (pgjdbc), not in Fedora
- One called pgjdbc-foss, only in Fedora, not mentioned anywhere else
- One called pgjdbc-foss-osgi, only in Fedora, not mentioned anywhere
else, which will create even confusion against the non-osgi one

     Plus the huge burden of maintaining two! forks of pgjdbc.

     I believe it's more KISS to just re-write the OSGI stuff used in
pgjdbc, license that PostgreSQL, and you're good to go, with a pure FOSS
package.

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

     Right. We can work on fixing them and submitting a PR.

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

     I think this is a matter of taste. I believe having a separate
package for the osgi interfaces that you are "copying" to provide a
compatibility layer belong to a separate project, and hence two
tarballs. But if that would be a showstopper, it could be integrated
into pgjdbc itself. But I'd wait for other's (pgjdbc core) opinion here
before doing that.
>
>> 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.

     OK, nothing against that :)

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

     I'm sorry I'm not that familiar with pgjdbc test suite, but post a
separate message to this list with the errors you encountered to check
them :)

     Thanks for all your input!

     Álvaro


--
Álvaro Hernández Tortosa


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