Re: Complicated re-distribution of pgjdbc the "open source way" - Mailing list pgsql-jdbc
From | Pavel Raiskup |
---|---|
Subject | Re: Complicated re-distribution of pgjdbc the "open source way" |
Date | |
Msg-id | 2249618.FUIZcbYCue@nb.usersys.redhat.com Whole thread Raw |
In response to | Re: Complicated re-distribution of pgjdbc the "open source way" (Matteo Melli <matteom@8kdata.com>) |
List | pgsql-jdbc |
Thanks for the comment. I still think that we should fix upstream, can we? But .. On Tuesday 08 of March 2016 11:05:33 Matteo Melli wrote: > 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 Thanks for the patches. Yes, Pavel wrote similar ones few months back in https://fedorapeople.org/cgit/pkajaba/public_git/postgresql-jdbc.git > From there to generate a spec should be quite straightforward. It is not completely straight-forward for other distributions. Those changes need to be done at one place. > 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. Agreed. > 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. That is why things like drivers should not _unconditionally_ depend on some non-free, hardly useful dependencies. Consider yourself starting some thin-range oriented distribution from scratch -- you'll be glad to hear that upstream allowed you to opt-out features that are redundant for you. > 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. Right, but it is no need to have that patch in Gentoo, Red Hat Enterprise Linux, Fedora, Arch, ..., *BSD, etc. It is better to write it once and don't push everybody in this chain reinvent the patch (or C&P is from one package to another). Pavel > > Matteo > > 2016-03-08 1:02 GMT+01:00 Álvaro Hernández Tortosa <aht@8kdata.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 > >>> > >>> > >
pgsql-jdbc by date: