couchdb can't install into userdir

[posita (Matt Bogosian)]

Staging couchdb fails on attempt to set group in non-root install. main.log is attached. Relevant part:

:debug:destroot Executing proc-post-org.macports.destroot-destroot-0
:error:destroot org.macports.destroot for port couchdb returned: xinstall: Unknown group couchdb
:debug:destroot Error code: NONE
:debug:destroot Backtrace: xinstall: Unknown group couchdb
    while executing
"$post $targetname"

Note: +no_root has no effect:

% port install couchdb +no_root
[still fails on unknown group]

[posita (Matt Bogosian)]

couchdb/main.log

[posita (Matt Bogosian)]

This work-around seems to get it built and installed:

--- [__MACPORTS_ROOT__]/var/macports/sources/rsync.macports.org/release/tarballs/ports/databases/couchdb/Portfile.orig    2013-07-15 09:03:12.000000000 -0700
+++ [__MACPORTS_ROOT__]/var/macports/sources/rsync.macports.org/release/tarballs/ports/databases/couchdb/Portfile 2013-09-02 21:28:36.000000000 -0700
@@ -51,13 +51,13 @@
                         --with-erlang=${prefix}/lib/erlang/usr/include \
                         --enable-js-trunk

-set dbgroup             couchdb
-set dbuser              couchdb
+set dbgroup             [__USER__]
+set dbuser              [__USER__]
 set logdir              ${prefix}/var/log/couchdb
 set dbdir               ${prefix}/var/lib/couchdb
 set confdir             ${prefix}/etc/couchdb
 set rundir              ${prefix}/var/run/couchdb
-set plistdir            /Library/LaunchDaemons
+set plistdir            ${frameworks_dir}/../LaunchDaemons
 startupitem.uniquename  org.apache.couchdb
 set plist               ${startupitem.uniquename}.plist

(Where "[__USER__]" is the installer's username.)

[posita (Matt Bogosian)]

Actually, I take it back. This is bad:

...
set plistdir            ${prefix}/Library/LaunchDaemons
...

It overwrites the .plist file and instead creates a soft link from [__MACPORTS_ROOT__]/Library/LaunchDaemons/org.apache.couchdb.plist to itself (which is not what we want). This is better (but incomplete):

--- [__MACPORTS_ROOT__]/var/macports/sources/rsync.macports.org/release/tarballs/ports/databases/couchdb/Portfile.orig    2013-07-15 09:03:12.000000000 -0700
+++ [__MACPORTS_ROOT__]/var/macports/sources/rsync.macports.org/release/tarballs/ports/databases/couchdb/Portfile 2013-09-02 21:50:49.000000000 -0700
@@ -51,8 +51,8 @@
                         --with-erlang=${prefix}/lib/erlang/usr/include \
                         --enable-js-trunk

-set dbgroup             couchdb
-set dbuser              couchdb
+set dbgroup             matt
+set dbuser              matt
 set logdir              ${prefix}/var/log/couchdb
 set dbdir               ${prefix}/var/lib/couchdb
 set confdir             ${prefix}/etc/couchdb
@@ -74,7 +74,7 @@
         ${destroot}${dbdir} \
         ${destroot}${logdir} \
         ${destroot}${rundir}
-    system "cd ${destroot}${plistdir} && ln -sf ${prefix}${plistdir}/${plist}"
+    #system "cd ${destroot}${plistdir} && ln -sf ${prefix}${plistdir}/${plist}"
 }

 post-activate {

This allows creation of [__MACPORTS_ROOT__]/Library/LaunchDaemons/org.apache.couchdb.plist but does not link it to (e.g.) ${HOME}/Library/LaunchDaemons, as it probably should for non-root installs. (See .../devel/dbus/Portfile as a decent example of supporting +no_root with LaunchDaemons.)

[mf2k (Frank Schima)]

In the future, please fill in the Port field.

[jeff@…]

Thanks for letting me know about this. I'll look into it as soon as I'm done with the 1.4.0 update.

[ryandesign (Ryan Carsten Schmidt)]

You've filed a similar request for mongodb in #40364 but I consider the no_root variant a weirdness of the dbus, akonadi and kdelibs4 ports that should not be perpetuated into other ports. Rather, we should work on removing the variants from those ports.

First off, variants whose names begin with "no_" have been deprecated for years and no new variants with that naming structure should be created.

Second, couchdb, mongodb, etc. install servers that want to be started as system-wide daemons. The ports set this up, but writing to the system-wide LaunchDaemons directory requires a root MacPorts install. If your MacPorts install is non-root, then you are intended to edit macports.conf and set startupitem_type to none so that MacPorts doesn't try to install the system-wide launch daemon, and you will then be responsible for arranging your own startup mechanism for the server outside of MacPorts (e.g. by writing your own launch agent plist). The ports should still install all the other needed parts into your prefix, but ports should never install things into the user directory outside the prefix. If just editing macports.conf and setting startupitem_type to none does not allow you to install the port, we can address getting that to work -- but preferably without adding a variant. For example, the port could inspect the installing user, and if it's not root, change dbuser and dbgroup to be the macportsuser.

[posita (Matt Bogosian)]

My apologies, I was unaware of the desire to remove no_* variants.

It may be desirable to have couchdb and mongodb run as system-wide daemons as a default, but it should not be required. There are cases where it is extremely beneficial for a non-root user to be able to install and run them from a well-supported software management system (like MacPorts) without error (e.g., for development purposes, where there may be a desire to run as many concurrent instances as branches being actively developed).

My tickets (this and #40364) have been filed under my (perhaps erroneous) assumption that supporting non-root user MacPorts installations is desirable. (I seem to recall reading support for that assumption somewhere, although I forget where.)

If these are not helpful, then I apologize. It is not my intention to frustrate.

[posita (Matt Bogosian)]

@Jeff, I just thought I'd pass along that this still appears to fail with 1.4.0. I didn't know if you were planning to look into a fix with that version.

[posita (Matt Bogosian)]

FYI, this is still an issue (but the above hack should still work) with 1.5.1.

(The version number for this ticket is wrong, it should have been 1.3.?, but I'm pretty sure it can safely be changed to 1.5.1 at this point.)

[posita (Matt Bogosian)]

Still an issue with 1.6.1.

[posita (Matt Bogosian)]

Looks like it's still an issue with 1.7.1.