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

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