Re: Complicated re-distribution of pgjdbc the "open source way"

Hi all,

As asked by Alvaro this is the link to the patch and instruction to remove
JNA and Waffle from the driver and to generate a package for the
problematic osgi interface:
http://www.postgresql.org/message-id/CAKFrgp8Qgj32NcJiDdfPMnrPU=wY=KKR+BKX86G71N3i=2dUPg@mail.gmail.com

From there to generate a spec should be quite straightforward. I suggest to
use maven instead of ant to build project since modification to the pom can
be handled easily by macros from javapackages-tools and it make easier
dependency resolution thanks to xmvn.

As Árpád mentioned this approach will require to maintain the package when
things break. Anyway, after touching the process of migrating a package
from Java world (or better say maven world) to distribution packaging, I
can say that the greater effort has to be put in dependency handling. An
that always bring the need to maintain the spec file. I think that if the
patch is not so big it should be ok as an extra cost to add, and, I think,
this is the case.

Matteo

2016-03-08 1:02 GMT+01:00 Álvaro Hernández Tortosa <aht(at)8kdata(dot)com>:

>
>
> On 08/03/16 00:49, Árpád Magosányi wrote:
>
>> Hola Álvaro,
>>
>
> Hi Árpád, thanks for your Spanish salutation :)
>
>>
>> Just some observations. We've been there and done that with upstream.
>> Maintaining a package with patches this way can easily get to be a big
>> burden. At some point it becomes a habit, and the big bad surprise comes
>> when you want to upgrade after a period of lazyness..
>>
>
> That's surely true. However, the suggested patch to maintain (please
> see the code when submitted here) is minimal. Indeed, it's not code per se.
> It's just removing some sections of the code -and their dependencies- that
> while useful upstream do not make sense in Fedora (like a Windows
> subsystem).
>
> Indeed, it makes sense packager's patch mechanism. After all, you may
> not need stuff that upstream *does* want to have (like, again, Windows
> stuff). But obviously, upstream cannot be forced to dump that stuff.
>
> I doubt maintaining this kind of patches should become a burden. They
> are not growing and/or diverging patches, but rather static and
> straightforward to adapt if upstream modifies related files.
>
> I do not want to have a stand on the underlying conflict. Maybe the
>> healthy github pulse and the quick, accepting treatment of #252 are just
>> misleading me... 3:)
>>
>
> I guess you're referring to https://github.com/pgjdbc/pgjdbc/pull/252
> That was ant, and now we're on maven. Things may or may not be different,
> but as I have so far seen, upstream is not considering removing these
> dependencies as of today, and that's why a fork has been suggested.
>
> _If you do think that there will be things which should be permanently
>> patched_ , I would recommend the following to keep the gap (hence
>> maintenance burden) as small as possible:
>> - Use a fork on github.
>>
> Could be a nice way of maintaining it.
>
>> - Have integration branches for all important upstream branches, where a
>> CI job continously merges upstream and tests whether it is still working.
>>
> Right.
>
>> - Open a pull request in upstream for every commit you have. Give them a
>> chance to sync up.
>>
>
> As I mentioned, I don't think this will work. The patches that Fedora
> requires are considered necessary by upstream, as they make sense there
> (but not in Fedora). That's why there's all this discussion ;P
>
> - Change only what is absolutely necessary, including not just code, but
>> also development practices and standards.
>>
>
> I would keep it to the minimal, for sure.
>
>
>> Side note: My understanding of maven is that you can exactly control
>> your direct dependencies in the pom, and you can have a list including
>> transitives with the dependency plugin. You can check and abort build if
>> an unexpected dependency comes up. So no need to have an inferior build
>> system just because dependencies.
>>
>
> I'm not sure if I got what you mean here, but if you mean ant is an
> inferior solution the answer is yes and pgjdbc will not move back to and,
> maven is the choice and for good reasons.
>
> Thanks for your comments,
>
> Álvaro
>
>
> --
> Álvaro Hernández Tortosa
>
>
> -----------
> 8Kdata
>
>
>
>
>>
>> On 03/07/2016 10:21 PM, Álvaro Hernández Tortosa wrote:
>>
>>> Hi Pavel.
>>>
>>> As you are well aware :) we (as in 8Kdata) are packaging ToroDB,
>>> java software that relies on pgjdbc. Since we saw that this issue was
>>> not moving forward, we investigated the issue on our own.
>>>
>>> While as of today the current ToroDB spec that we have is
>>> depending on an older version of JDBC --which is highly undesirable--
>>> we have also built a simple mean of packaging pgjdbc for Fedora
>>> without having to modify upstream.
>>>
>>> Since RPM packages allow (and some of them heavily use) patches
>>> against upstream, this is easy to accomplish. Having a parent pom is
>>> neither a problem --it is packaged as a subpackage (might not be
>>> ideal, but hey, it works, and it doesn't harm). All in all, with all
>>> the obvious advantages and disadvantages, we have working source code.
>>> Rather than a will to patch upstream or fork pgjdbc, we have a working
>>> spec that packages pgjdbc, removing (by patching) all the non-foss and
>>> windows dependencies and code, and packaging the parent pom too.
>>>
>>> I believe iterating over this effort is better than either forking
>>> or patching upstream.
>>>
>>> I don't have the code, but Matteo (cc'ed), who did this work, will
>>> share it tomorrow.
>>>
>>> I'd suggest to work on this, which seems to me as a compromise
>>> solution, and agree all on this solution, rather than plan longer-term
>>> plans that, while ideal for some, aren't for the rest and, and above
>>> all, will take significantly more effort. Our main goal is to deliver
>>> packaged and foss pgjdbc to the users asap, and here we have an
>>> already working solution.
>>>
>>> Matteo, please share the code whenever possible.
>>>
>>> Cheers,
>>>
>>> Álvaro
>>>
>>>
>