Re: [pgjdbc] Implement JDBC specs via pre-processor step (#435)
От | Pavel Raiskup |
---|---|
Тема | Re: [pgjdbc] Implement JDBC specs via pre-processor step (#435) |
Дата | |
Msg-id | 1760147.kSfhyxqH6i@nb.usersys.redhat.com обсуждение исходный текст |
Ответ на | Re: [pgjdbc] Implement JDBC specs via pre-processor step (#435) (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>) |
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления:
Предыдущее
От: Vladimir SitnikovДата:
Сообщение: Re: [pgjdbc] Implement JDBC specs via pre-processor step (#435)
Следующее
От: Pavel RaiskupДата:
Сообщение: Re: Step towards being able to build on Linux (Pull request #435)