Re: Complicated re-distribution of pgjdbc the "open source way" - Mailing list pgsql-jdbc

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