Re: How other package pgjdbc

     Hi everybody. Top-posting here to avoid getting into finer detail,
providing more general opinion here.

     To me the value of having pgjdbc packaged for Fedora/Red Hat, and
having it up to date, is undeniable. So let's find the ways to get it
done :)

     Now I don't see productive analyzing one by one whether the
dependencies should be individually packaged or not. This is a very
common problem (or feature, as you may see it) of Java development, and
resolving it on a use-by-use case won't help. This kind of requires a
more general solution.

     It is a good question why there are not packages like OSGI in rpm
already packaged. I understand the database team does not want to
maintain such package. What I see here is that there's a significant
"impedance mismatch" between distro packaging and Java. I strongly
believe this is the main reason there are few Java packages in the
distros, not that few users need it. Most Java users that use most Java
programs, in my experience, either download compiled, "fat" JARs (all
dependencies included) or use Maven. Few use pre-packaged distro
software (usually because it's unavailable).

     And again, the reason for this is that Java development tends to
include one or several dependencies, and the ecosystem of dependencies
is huge (in my POV greater than any other language ecosystem, and by
far). So we have to consider one of the following two alternatives:

- Take every dependency on any Java software to package (pgjdbc in this
case) and also package it as a separate package. This IMHO might get
crazy with other projects with more dependencies, since that may split
the process into even dozens of packages.
- Take the source of those dependencies, install it locally prior to
package building, and provide all as a single unit.

     The first method might be a burden on the packagers and might not
be convenient in many senses. The second one is thus probably the best
one. It might sound terrible if several packages will end up packaging
the same code and not reusing it; but in Java (different apps) this is
hardly a problem (as it is in C with shared libraries).

     So I'd suggest to focus on this second approach. Whether we like
OSGI or not, it is a feature of the current driver, and should not be
removed lightly. It diminishes its value. However, I understand that it
may not be packaged individually (more packages to maintain). So mi big
question is:

Can OSGI dependency be pulled -as source, of course- into build
preparation phase, compile locally (mvn install or any alternative mean)
and ship it integrated with the pgjdbc package?

     Cheers,

     Álvaro



On 25/01/16 16:33, Pavel Raiskup wrote:
> On Monday 25 of January 2016 15:33:18 Pavel Raiskup wrote:
>> On Monday 25 of January 2016 08:46:56 Dave Cramer wrote:
>>> Well like it or not, spring is arguably the largest enterprise java
>>> dependency and it has hundreds if not thousands of dependencies which
>>> enterprise users happily download.
>> I can concur with you, Dave.  There are people who are OK with that.
>>
>>> So I'm not sure how your argument holds water.
>> Sure.  You may choose to force users to use maven everywhere, via not
>> allowing us to build from source.  But I'm here please you not to do that.
>>
>>> I would imagine from a redhat perspective redhat is the only trusted
>>> source.  However this is 2016 and the sheer volume of dependencies
>>> modern software requires makes this presumption untenable.
>> Substitute Red Hat with any Linux, FreeBSD, Solaris etc. distributions.
>> All of those are used and trusted.  At least nowadays -- making this
>> totally off-topic is not worth;  I'm just trying to build from source.
>>
>> Believe it or not -- there are people who do not trust maven repositories
>> -- and I'm not sure whether PostgreSQL project should encourage people to
>> use maven repositories everywhere.  PostgreSQL should be re-distribuable
>> everywhere, if possible.
>>
>>> This argument is not constructive but an attempt to show another point
>>> of view.
>> Ack.
>>
>>> I have asked to join the osgi-dev list and will ask them how to deal
>>> with this issue
>> Right, but our mission is to distribute pgjdbc, not OSGi (which is
>> something osgi-dev will tell you probably).  If we could opt-out it, it
>> would be fine.
> Just a quick observation while trying to convince you that GNU/Linux
> distributions do care about pgjdbc package-ability:
>
> Gentoo build scripts:
> https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-java/jdbc-postgresql/jdbc-postgresql-9.4_p1206.ebuild
> Which is something I'm trying to avoid, but yes -- they were able to
> rebase to 1206 thanks to those hacks.
>
> Arch linux has pgjdbc in AUR repository.  It means that there is no
> support -- the reason is because they do not build from source;  they
> download the binary from upstream repository.
> https://aur.archlinux.org/packages/postgresql-jdbc/
>
> Debian has already been discussed.  Way too old packages.
>
> OpenSUSE (9.4.1201):
> https://build.opensuse.org/package/view_file/openSUSE:Leap:42.1/postgresql-jdbc/postgresql-jdbc.spec?expand=1
>
> Pavel
>