[SRU] R_HOME environmental variable not set

Confirmed in Gutsy, Feisty, Edgy, and Dapper.

Dapper version requires additional love:
root@gandalf:/# sudo -u postgres psql plr_test < /usr/share/postgresql/8.1/plr.sql
SET
ERROR: could not load library "/usr/lib/postgresql/8.1/lib/plr.so": libR.so: cannot open shared object file: No such file or directory
ERROR: function plr_call_handler() does not exist
ERROR: could not load library "/usr/lib/postgresql/8.1/lib/plr.so": libR.so: cannot open shared object file: No such file or directory
ERROR: could not load library "/usr/lib/postgresql/8.1/lib/plr.so": libR.so: cannot open shared object file: No such file or directory
ERROR: could not load library "/usr/lib/postgresql/8.1/lib/plr.so": libR.so: cannot open shared object file: No such file or directory
ERROR: could not load library "/usr/lib/postgresql/8.1/lib/plr.so": libR.so: cannot open shared object file: No such file or directory
ERROR: could not load library "/usr/lib/postgresql/8.1/lib/plr.so": libR.so: cannot open shared object file: No such file or directory
ERROR: relation "plr_environ_type" already exists
ERROR: could not load library "/usr/lib/postgresql/8.1/lib/plr.so": libR.so: cannot open shared object file: No such file or directory
ERROR: function plr_environ() does not exist
ERROR: relation "r_typename" already exists
ERROR: language "plr" does not exist
ERROR: language "plr" does not exist
We need to use fix from http://bugs.debian.org/360796.

Attached debdiff for Gutsy should fix this.

NOTE: you will have to install plr build-dependencies to regenerate source package.

This looks clean enough but you might want to ping Martin Pitt (pitti) since he appears to be the maintainer. Thanks for the patch!

Martin: can you check this one out?

This is not quite sufficient, I'm afraid. You cannot assume that there is only one 8.2 cluster, and that it is called 'main'. That is the default after a clean installation, but people are free to create arbitrarily many clusters.

So you should iterate over "pg_lsclusters -h" to find out valid cluster versions and names, and do the R_HOME thing for all of them.

Thanks for your feedback, Martin.
I attach a new debdiff which should cover your suggestion.

Luca,

thanks, this already looks better. Still some issues:

 * The postinst loop does not check whether R_HOME is already set. So every installation or upgrade of plr would add another R_HOME to the file, and this would even override an admin's setting which points to somewhere else.

 * The postrm loop will fail and bail out if the environment file does not exist (which is legitimate).

Again, thanks for the feedback and sorry for bothering you more than necessary :)

OK, seems I still managed to overlook some things, and there are some new issues:

 * The grep and thus the postinst will fail if 'environment' does not exist.
 * stylistic: IMHO this would be easier to read: if ! grep -q "^R_HOME" /etc/postgresql/$cluster/environment
 * The postrm should do cleanup only on "purge", not on the other actions; in particular, doing it on "upgrade" is actively wrong.

Please see http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html for details.

Thanks for bearing with me!

New debdiff should fix some issues. I've also added another switch which creates environment file if not present.

Sorry for the delay and thanks for your patience.

Luca,

that patch looks good now, thank you!

Dirk just made a good point in the corresponding Debian bug. It is probably much easier to hardcode that value as a fallback in the plr source itself than to muck around with the environment file.

It could be a better solution, lesser code required and no risks to have problems in postgresql.
I will try to find a solution this way in the next days. Thank you for pointing this out.

Attached debdiff implements the above solution.

Luca, that looks good. I just fixed the indentation and used simple-patchsys.mk (I like cdbs better than dpatch). I uploaded a new Debian revision with that fix and synced it to Gutsy.

Thank you!

plr (1:8.2.0.1-2) unstable; urgency=low

  * Move packaging to cdbs.
  * Add debian/patches/R_HOME_default.patch: Fall back to /usr/lib/R if R_HOME
    is not defined. This is pretty much a constant in Debian and Ubuntu, and
    doing it with an implicit default is much more elegant than hacking in
    configuration files. Thanks to Luca Falavigna for this patch!
    Closes: #439270 and LP: #130059

 -- Martin Pitt <email address hidden> Fri, 24 Aug 2007 17:42:15 +0200

Thanks Martin!
What about SRUs? Do you think it's worth to manage them?

Luca,

yes I think this would make a fine SRU. I guess the patch will more or less apply to previous versions, too, but there are some different build systems, etc. For SRUs, please do not introduce dpatch, just apply it inline. Please attach debdiffs for dapper and feisty, I will review them and sponsor if necessary. (NB that I'm on honeymoon for the next 14 days, though, so please poke cjwatson for approval and #ubuntu-motu for sponsoring).

Thanks a lot!

I fear I can't just apply this fix inline because source files are into a tarball and they are uncompressed at build time.
I'm not aware of a solution without using a patch system, even a homemade one.

Ah, I see. You need to apply the patch in debian/rules then, no problem.

Debdiff for feisty-proposed.

Debdiff for edgy-proposed.

Debdiff for dapper-proposed.

Thanks. Feisty looks good. For Dapper and Edgy, please revert the Maintainer: change (that hasn't been tested with dapper/edgy package tools).

For Dapper: Please give a rationale and a bug number for the rpath addition in the changelog.

Debdiff for edgy-proposed after Maintainer change removal.

Debdiff for dapper-proposed after Maintainer change removal and changelog integration.

For my reference: while preparing SRU proposals, is XSBC-Original-Maintainer required for Feisty and newer only?

debdiffs look good now, thank you! Please upload.

> while preparing SRU proposals, is XSBC-Original-Maintainer required for Feisty and newer only?

Right.

I sponsored the uploads and accepted them to {dapper,edgy,feisty}-proposed. Please go ahead with QA testing.

"Fix tested succesfully on Dapper, Edgy and Feisty

Works for me too on dapper, edgy and feisty. Bye

Seven days testing period elapsed and two persons confirmed the fix is good on each version.
Tagging with verification-motu-done as per https://wiki.ubuntu.com/MOTU/SRU.

Copied to {dapper,edgy,feisty}-updates.