couchdb @1.2.1, couchdb-devel @1.4.0a-20130112_1 Clean up dependencies

[jeff-macports@…]

Several of the dependencies listed as lib dependencies are actually build dependencies. Those should be cleaned up and split into depends_lib and depends_build. (and possibly depends_run. Needs testing.)

[jeff@…]

Cc Me!

[jeff@…]

couchdb-devel was done with r104096. patchfile for couchdb attached. Use version 2, couchdb.37651.2.patch. As far as I can tell, autoconf, automake, and libtool are not actually needed to build the release tarballs as they are already bootstrapped. Let me know if I'm wrong about that. It builds fine without MP auto{make,conf} installed, and the system installed ones disabled.

This doesn't affect the build, so I don't think a revbump is needed. Feel free to bump it if you feel differently.

[jeff@…]

Could a committer take a look at this please?

[larryv (Lawrence Velázquez)]

Do the additional dependencies change the linkage in the installed files?

[jeff@…]

Possibly. It depends on if the end user had curl installed already or not. Curl was not previously listed as a dependency even though it does depend on it. If curl was not already installed it quietly used the system curl.

Before:

./src/couchdb/priv/couchjs:
        /usr/lib/libcurl.4.dylib (compatibility version 6.0.0, current version 6.1.0)
        /opt/local/lib/libjs.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)

After:

./src/couchdb/priv/couchjs:
        /opt/local/lib/libcurl.4.dylib (compatibility version 8.0.0, current version 8.0.0)
        /opt/local/lib/libidn.11.dylib (compatibility version 18.0.0, current version 18.9.0)
        /opt/local/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.2.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
        /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0)
        /opt/local/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
        /opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
        /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.7)
        /opt/local/lib/libjs.dylib (compatibility version 0.0.0, current version 0.0.0)

What is the preference in situations like this?

[larryv (Lawrence Velázquez)]

We don’t want some users having “old” @1.2.1_2 with system linkage and other users having “new” @1.2.1_2 with MacPorts linkage, so we’ll go with a revbump. r104575.