Re: PL/Java 1.5.1 - Mailing list pgsql-pkg-debian

From Christoph Berg
Subject Re: PL/Java 1.5.1
Date
Msg-id 20181016113214.GA3027@msg.df7cb.de
Whole thread Raw
In response to PL/Java 1.5.1  (Chapman Flack <chap@anastigmatix.net>)
Responses Re: PL/Java 1.5.1  (Chapman Flack <chap@anastigmatix.net>)
List pgsql-pkg-debian
Re: Chapman Flack 2018-10-16 <5BC54F32.7020705@anastigmatix.net>
> 1. It looks as if they are being built with libjvmdefault => java 8.
>    Do some of the distro releases they are being built for have a later
>    version of Java as the default? (If I'm looking in the right places,
>    it seems that the Ubuntu default-jdk-headless is 8 for xenial and
>    artful, 10 for bionic, 11 for cosmic. Debian's default-jdk seems to
>    be 7 in wheezy and jessie, 8 in stretch, 10 in buster and sid,
>    11 in experimental).

Seems about right.

>    It might be nice to build pljava packages where libjvmdefault => the
>    default version for the release. It still has to be /built/ with 8, but
>    can then run with the later versions on releases that have them. The
>    user can always set pljava.libjvm_location to a different version, but
>    this would have the property that leaving it alone means getting the
>    expected Java version, and (in recent releases) having access to newer
>    Java features, without having to take extra steps.

Currently pljava.libjvm_location is set to the jvm version the package
was built with. The .deb will have this dependency:

Depends: ${jre:Depends} | default-jre-headless

The first problem here is that this is missing "| java-runtime-headless"
to allow arbitrary jre versions.

What we probably should to is to change this to

Depends: default-jre-headless | ${jre:Depends} | java-runtime-headless

Apt doesn't consistently pick the first alternative, but there's rule
that the preferred one should come first.

... and also point pljava.libjvm_location at the default version.

> 2. You seem to be building packages for PG from 11 back to 9.3. For that
>    range of PG versions, it would be possible to add the -Psaxon-examples
>    option on the build command (if you can stomach having the 5 MB
>    Saxon-HE-9.8.0.14.jar as a build dependency). The jar can be left out
>    of the package as an optional runtime dependency. The Saxon examples
>    would just be included in the pljava-examples jar, they would get
>    automatically loaded in PG if the user installs the jar. They wouldn't
>    work unless the user also installed the Saxon-HE jar, but that would be
>    the only step needed for someone who might want to try them.
> 
>    It's actually safe to add -Psaxon-examples when building for any PG
>    version back to 8.4. Before 8.4, those examples can't be included
>    in pljava-examples.jar because their deployment SQL commands would
>    be syntax errors and prevent installing the jar, which is why I made
>    the build option.

I'm not really following how that relates to the range of PG versions?
Because it's "only" 8.4+ ?

> 3. Here is the possibly outlandish thought: I see in
>    pool/main/p/postgresql-pljava/ that there are existing .debs in there
>    for PG 9.2 back to 8.1, and they are based on really ancient PL/Java
>    versions with serious known bugs. I have been taking pains to make sure
>    PL/Java 1.5.x stays buildable back to 8.2 (but not 8.1, sadly). It would
>    be great if there could be packages in the repo so that those old buggy
>    ones would not be the only ones available. I understand that your build
>    arrangements probably don't even have those six PG versions present to
>    build against, and there is probably no justification for doing ongoing,
>    automated builds for them. Even if it were possible to just do one round
>    of builds and leave them there (as it appears those old packages are
>    simply left in the directory from years ago), that would benefit anyone
>    who needs, for some reason, to use such an old PG version.

Some of the very old packages were not built on/for apt.pg.o but
copied over from Debian. The oldest PG version we have is 8.2, which
I'm still keeping alive, but in sid-pgdg only. The other distributions
have what was supported while they were alive, so the window of
package versions updated shifted over time.

We are usually not updating modules for PG versions that aren't
supported anymore, just to cut the maintenance down, but we could
probably give the older PG versions a one-time try. (This wouldn't
extend to unsupported distributions, though - the build chroots are
gone.)

> Someone has actually opened a PL/Java issue this week who is using
> PG 8.3. :)  I did not press for details about why.... That's on Windows
> though.

... that doesn't make it any better :P

Christoph


pgsql-pkg-debian by date:

Previous
From: apt.postgresql.org repository
Date:
Subject: pg-similarity updated to version 1.0-2.pgdg+1
Next
From: apt.postgresql.org repository
Date:
Subject: pgfincore updated to version 1.2.1-2.pgdg+1