[Pkg-postgresql-public] PL/Java packaging

[Martin Pitt]

--J2SCkAp4GZ/dPZZf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi!

Peter Eisentraut [2005-06-02 18:02 +0200]:
> I've started packaging PL/Java and I think it's time to discuss some=20
> issues to make the packaging of plugins consistent.  So...

That would be nice. I will adapt the server-side packages of Ubuntu
Breezy to the new architecture in this week, so we should come to an
agreement.

> Package name: Since all plugins are tied to the server version, I think=
=20
> the server version ought to appear on the package name (like for binary=
=20
> Python packages).=20

Right.

> So I went with postgresql-8.0-pljava.

Hm, that's a bit inconsistent with the scheme we already used for
other PostgreSQL packages like
postgresql-{client,doc,contrib}-version, but it is consistent with the
Python packages. And since it is the PostgreSQL version 8.0 and not
the pljava version, I think this scheme makes sense.

> Should there also be a metapackage postgresql-java that pulls in the
> "preferred" version (also like for Python packages)?  I guess so.

Hm, I rather wouldn't do that. There is no "preferred" version for the
PostgreSQL server, at least not at the moment. You have to install the
matching server version (it should be drawn in as a dependency of
-pljava). Since we could still add it later, can we leave it for now
and see how it goes?

> Installation location: Should plugins be installed into the server's=20
> pkglibdir, so they are automatically found, or to private directories,=20
> or perhaps to a designated third directory that we add to the server's=20
> path?

I think the requirement is that createlang should work out of the box.
Thus option 1 would work with the current packages and I don't have a
problem with it. Option 3 is cleaner, though. Since
"dynamic_library_path" defaults to $libdir, can $libdir be made to
contain two paths by default? If so, I'd upload new 7.4/8.0 packages
with this change very quickly (I have to fix tsearch2 anyway) to
support this.

> On a different issue, what would you prefer: (a) pljava compiled with=20
> gcj that only works as untrusted language or (b) pljava compiled with=20
> Sun's JDK which works as trusted and untrusted language or perhaps both=
=20
> (or (c) pljava compiled with Kaffe which doesn't work at all)?

Hm, option (c) does not really sound useful... :-) I'd put a
p-8.0-pljavau in main (a) and a p-8.0-pljava into contrib (b) then
(unless you are fine with putting the whole package into contrib). I
prefer packages in main, but then again untrusted languages are much
less useful. I don't really have a strong opinion about that one.

Thanks,

Martin

--=20
Martin Pitt              http://www.piware.de
Ubuntu Developer   http://www.ubuntulinux.org
Debian Developer        http://www.debian.org

--J2SCkAp4GZ/dPZZf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCo+yQDecnbV4Fd/IRAvzrAKDdr59aAxOXwgXIHt1HrkB5Uo8gCgCfS5SW
+PfOjULmDGY7/inXr7qWttY=
=sm61
-----END PGP SIGNATURE-----

--J2SCkAp4GZ/dPZZf--