[Pkg-postgresql-public] Pl/R

[Martin Pitt]

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

Hi Stephen, hi Christopher!

On 2004-03-23 19:04 -0500, Stephen Frost wrote:
> * Christopher Browne (cbbrowne@ca.afilias.info) wrote:
> > 1.  /usr/lib/postgresql/lib/plr.so references libR.so
> >=20
> >    cbbrowne@dev6:~$ ldd /usr/lib/postgresql/lib/plr.so
> >          	libR.so =3D> /usr/lib/R/bin/libR.so (0x40020000)
> >=20
> > But ldconfig didn't know about this until I added "/usr/lib/R/bin" to
> > /etc/ld.so.conf and ran "ldconfig -v".  Is there a "standard" way for
> > dpkg to cope with that?
>=20
> That's an interesting problem...  We don't want packages making changes
> to ld.so.conf unless it's through some kind of defined interface and I'm
> not aware of any at the moment.  It'd be nicer if the R folks had just
> used the standard library paths. :/

Well, the symlink idea did not sound bad. Maybe the R maintainer can
install it (I think the symlinking really belongs there, not to
arbitrary packages depending on it - otherwise other packages may do
the same and this will crash). But OTOH if the libraries are linked
there, they can as well be put into /usr/lib in the first place,
can't they?

Policy seems to allow installing libraries into non-standard locations
but then ldconfig must not be used; however, it does not say anything
about how to handle libraries/programs depending on them...

> > 2.  The /etc/init.d/postgresql script needs to have "export
> > R_HOME=3D/usr/lib/R" added to it. =20
> >=20
> > Is there a decent 'standard' way of adding that in when pl/r is added
> > in?  It's only needed if postgresql-plr is installed...
>=20
> The only way I can think of would be to have a directory of environment
> variables under /etc/postgresql which will then be included by
> /etc/init.d/postgresql.  Kind of ugly, but we can't have packages
> modifying the /etc/init.d/postgresql script, that way leads to disaster.

This seems kind of ugly to me. Relying on environment variables does
not seem like a good idea. I would prefer to modify the sources to
fall back to a compile-time provided directory if R_HOME does not
exist. This could even be pushed upstream since it wouldn't interfere
with other installations. I just looked at the sources, it seems
pretty easy to do.

> On the issue of changes to the 'main' postgresql package- I've got
> something of a bigger one to request that can't really be done any other
> way I don't think.  To support some of the things that PostGIS can do
> the PostgreSQL server needs to be linked against libstdc++, from what I
> understand.  Can this be done?

Technically it should be not a big problem, but why on earth
postgresql should be linked against a library it does not need? Maybe
you can explain the problem a little more detailled? And/or submit a
wishlist bug agains postgresql, then we have a separate thread to
discuss this at.

> Many thanks for the changes to the package that I think I helped
> instigate-=20

Same thanks to you, you have been very helpful!

Stephen, are you actually interested in plr? If so, maybe you would
like to maintain it together with Christopher?

Thanks and have a nice day!

(BTW, please don't cc me, I'm subscribed to the list. Thanks)

Martin

--=20
Martin Pitt                 Debian GNU/Linux Developer
martin@piware.de                      mpitt@debian.org
http://www.piware.de             http://www.debian.org

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

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

iD8DBQFAYwkjDecnbV4Fd/IRAkuAAJ4y5ZkO0IYlJO4pktSom/X500zypwCg1uxm
vnvKwunER79Ci1OmDXzv1V8=
=UBMy
-----END PGP SIGNATURE-----

--IS0zKkzwUGydFO0o--