Re: [pgjdbc] Implement JDBC specs via pre-processor step (#435)

Hi all, and sorry for the delay. And for long mail.

On Friday 22 of January 2016 10:42:49 Vladimir Sitnikov wrote:
> What we miss is:
> 1) Fedora-like CI environment. It makes little sense optimizing
> pgjdbc's dependencies if those dependencies are already present in
> Fedora-like build boxes.

Build boxes:
RPM distributions usually build package in "mock" tool [1], which is
basically chroot. There is really minimal set of packages, but
particular package build can request additional packages (if those are
available in official/trusted package repositories). Thus each package
has slightly different builder configuration.

Dependencies:
Just a note that IMO optimizing dependencies is always worth.
Fedora/Ubuntu/Windows is just subset of platforms available in the wild.
Anybody on platform "Foo" can take the source and build it itself and
each dependency makes the work harder.
IOW, as a user:
1. I have JDBC installed and PostgreSQL, I need a glue -- pgjdbc
2. Let's compile
3. I can't compile, there is dependency (a), (b), (c)...

That's why I think that things like osgi/waffle should be supported, but
only as an optional dependency. Neither jdbc nor PostgreSQL needs the
dependency a b c, and as a connector between jdbc/postgresql any new
hard dependency hurts :(.

> Is there a CI for Fedora builds?

Yes. We can assist with this, having this in pgjdbc would be awesome.
Copr [2] build system should be able to take github repo branch and spin a
new build of RPM package. This probably does not show "green OK icon" on
github page (yet), but anybody can receive fedmsg [3] about successful
build or check manually that the build is OK.

Testsuite possibilities are limited, because the build-environment is
not able to do administrator tasks or some hard integration testing, but
those should not be needed in case of jdbc driver.

> How do we validate that "the specific changes to pgjdbc" indeed help
> Fedora packaging?

We can tell you it helps, as Fedora packaging is still our responsibility.
But yes, we should setup CI. And any interest of upstream in Fedora
packaging is huge success.

I would correct your question by s/Fedora/RPM/ pattern though; all RPM
[4] distributions would benefit from changes we talking about.

> 2) Requirements. I'm sure the first dozen of builds will fail due to
> packaging limitations. It is much better to know the limitations
> beforehand than running into them at Fedora CI builds.

To answer this, I need to know what limits you mean probably. Fedora
builds are turing complete, there are just intentional limits (which
encourage packagers to do the job right) like no superuser access.
In CI [2], you can opt-in the internet; but it is generally a bad idea
(I admit that not everybody will agree with me) because it (a) makes me
lazy and (b) is not secure.

So
* no internet in official build system (but that is separate from CI),
* you have limited set of dependencies (usually new package gets added
on demand -- once somebody needs it), usually available on demand and
installed before the build starts
* no superuser access

[1] https://fedoraproject.org/wiki/Mock
[2] https://copr.fedorainfracloud.org/coprs/
[3] http://www.fedmsg.com/en/latest/
[4] https://en.wikipedia.org/wiki/Category:RPM-based_Linux_distributions

Pavel