[Pkg-postgresql-public] Bug#506728: postgresql-8.3-plr: Does not run ldconfig and does not set R_HOME in postgresql environment

Andreas Tille tillea at rki.de
Mon Nov 24 20:13:27 UTC 2008


On Mon, 24 Nov 2008, Martin Pitt wrote:

>> Am I allowed to eddit the environment file in the postinst of
>> postgresql-plr or what is the general policy for this case.
>
> In principle yes. The creation of that file was pretty much motivated
> by things like this in the first place, although primarily intended
> for user configuration.

Ah, OK.  This sounds reasonable.

> However, there are some things to consider:
>
> 1. There might be an arbitrary number (including 0) of
>   /etc/postgresql/MAJOR_VERSION/CLUSTER_NAME/ directories. So if the
>   semantics of -plr should be to allow using R in all already
>   existing clusters (which is not unreasonable IMHO), you should add
>   it to all of them.

In this case MAJOR_VERSION is always 8.3 (or any specific later number)
if I understood upstream correctly.  I have probably to loop through
CLUSTER_NAMEs.

> 2. This change won't have an effect for clusters which are created
>   after installation of -plr.

These cases should be covered by the included README.Debian.
I see no other chance to copy with this.

> 3. If you do this, please ensure not to add the environment variable
>   again if it is already present in the file (including whitespace
>   fuzzing).

Sure.  I would definitely grep for the variable before adding it.

> Of those, 2. is probably the trickiest problem.
>
> However, let's step back a bit. To be honest, the mere existance of
> this variable seems wrong to me, since it is pretty much an "unbreak
> my system" setting and violates Debian Policy 9.9.
>
> Can't -plr itself be patched to default to /usr/lib/R if R_HOME isn't
> set? With that, people can still set it to /usr/local/test/R or
> whatever, but it would work OOTB.

It seems as if there should be not that much instances of the R_HOME
variable to be changed:

6$ grep -R R_HOME * | grep -v -e ":[[:space:]]*/*\*" -e echo -e printf -e ":[[:space:]]*err" -e README -e '#' -e '^doc'
debian/rules:DEB_MAKE_ENVVARS:=USE_PGXS=1 R_HOME=/usr/lib/R
debian/rules:DEB_MAKE_INSTALL_TARGET:=USE_PGXS=1 R_HOME=/usr/lib/R install DESTDIR=debian/tmp/
Makefile:ifdef R_HOME
Makefile:r_libdir1x = ${R_HOME}/bin
Makefile:r_libdir2x = ${R_HOME}/lib
Makefile:r_includespec = ${R_HOME}/include
Makefile:R_HOME := $(shell pkg-config --variable=rhome libR)
Makefile:ifneq (,${R_HOME})
Makefile:override CPPFLAGS += -DR_HOME_DEFAULT=\"$(rhomedef)\"
pg_userfuncs.c: unsetenv("R_HOME");
plr.c:  r_home = getenv("R_HOME");
plr.c:          size_t          rh_len = strlen(R_HOME_DEFAULT);

> If that isn't possible, I have a thought on how to solve 2. more
> elegantly, but let's discuss the general approach first.

As I said - I would feel a proper documentation enough for PL/R - well
release teem does not even consider this package worth to enable our
users a smooth upgrade from Etch to Lenny :-(( so we can expect the few
users to read the docs.  But there might be other cases where s solution
for 2. is needed.

> Thanks, and "guten Abend",

Kind regards and "gleichfalls"

        Andreas.

-- 
http://fam-tille.de



More information about the Pkg-postgresql-public mailing list