db46 4.6.21_6 Extracting - failed

[senz@…]

Failed while upgrading:

--->  Fetching db46
--->  Attempting to fetch patch.4.6.21.1 from http://www.oracle.com/technology/products/berkeley-db/db/update/4.6.21/
--->  Attempting to fetch patch.4.6.21.2 from http://www.oracle.com/technology/products/berkeley-db/db/update/4.6.21/
--->  Attempting to fetch patch.4.6.21.3 from http://www.oracle.com/technology/products/berkeley-db/db/update/4.6.21/
--->  Attempting to fetch patch.4.6.21.4 from http://www.oracle.com/technology/products/berkeley-db/db/update/4.6.21/
--->  Attempting to fetch db-4.6.21.tar.gz from http://arn.se.distfiles.macports.org/db4/4.6.21_6
--->  Attempting to fetch db-4.6.21.tar.gz from http://distfiles.macports.org/db4/4.6.21_6
--->  Verifying checksum(s) for db46
--->  Extracting db46
Error: Move /usr/local out of the way then make this port.
Error: Target org.macports.extract returned: /usr/local is in the way
Error: Unable to upgrade port: 1

[matteocorti (Matteo Corti)]

Cc Me!

[jmroot (Joshua Root)]

Do what the error message says.

[matteocorti (Matteo Corti)]

Sorry? Moving /usr/local is not a solution on a production system where the directory is actually used. And why on earth should the build process need to "own/delete/modify" /usr/local? Matteo

[senz@…]

Do what? Delete dir? By what means i need to do this now. Why port doesnt complaint when i was installing it, or upgrading previously? It doesnt make any sense.

[mixal@…]

You can temporarily move /usr/local to /usr/somthing else. After the upgrade is complete, you can move it back. No idea why it's messing around with that directory, but it doesn't leave anything there or write out a new one.

However, to the maintainers:

macports is supposed to be in /opt/local. I don't go messing around there with non-macports packages. And by the same token, macports needs to stay out of directories out side of it's base. Letting things like this go just lead to confusion on the parts of users and is generally, IMO, a poor practice. Theoretically, I should be able to install macports, fink, and compile my own packages in in their own locations without stepping on each other and select which I want to use by adjusting my PATH. Let's make sure macports is playing nice with everyone else, please?

It's a good thing I didn't have any active processes in the dir, however. Moving it around is not the correct solution for a production system.

[mirimiri66@…]

Cc Me!

[songzw@…]

How to reopen this ticket? Or submit one new ticket?

[christophe.haro@…]

Replying to matteo.corti@…:

Cc Me!

I have the same problem, with exactly same error messages and I do not understand how to fix the problem.

[alex+mp@…]

Cc Me!

[alex+mp@…]

I have the same problem, and it definitely is a bug, so you should reopen this ticket and fix the bug: Messing with /usr/local is not an option, neither for me nor for MacPorts ports ...

[andreas@…]

It seems that some users have stuff in /usr/local that prevents this package from building. It is not an option to move /usr/local around though IMO. I removed the check in the portfile, and the package builds fine on my machine (10.6).

Go to /opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/db46/, open the file "Portfile" in your editor of choice and remove the section saying

pre-extract {
        if {[file exists "/usr/local"]} {
                ui_error "Move /usr/local out of the way then make this port."
                return -code error "/usr/local is in the way"
        }
}

or apply this patch to the file:

--- Portfile.old	2009-10-29 05:12:32.000000000 +0100
+++ Portfile	2009-10-29 11:46:47.000000000 +0100
@@ -57,12 +57,6 @@
 destroot.destdir        prefix=${destroot}${prefix} \
                                 docdir=${destroot}${prefix}/share/doc/db-${version}/
 
-pre-extract {
-        if {[file exists "/usr/local"]} {
-                ui_error "Move /usr/local out of the way then make this port."
-                return -code error "/usr/local is in the way"
-        }
-}
 
 post-destroot {
         foreach bin { archive hotbackup dump printlog upgrade checkpoint recover verify deadlock load stat codegen dump185 } {

[chris@…]

Cc Me!

[groblewis@…]

I just ran into this problem too. Moving /usr/local is not an acceptable workaround. As mixal said above: macports should stay out of the way of other software. Please fix this.

[oddsimons@…]

Seems to be introduced by [60013]. A really hopeless solution that creates much more problems than it solves... Please revert until a better solution can be found.

[dershow]

Cc Me!

[blair (Blair Zajac)]

The problem is that the build tools (gcc etc) have a liking to /usr/local which can't be worked around with consistency. The db46 compile can break pretty easily, so instead of people opening tickets just to tell them to move /usr/local out of the way this checks for the issue.

See these tickets

#18113 #18377 #18625 #18670 #21649 #21965

If you have a better solution, please suggest it.

[macports@…]

Cc Me!

[wlipa (Bill Lipa)]

Bailing in this way is pretty horrible, especially when /usr/local content isn't necessarily a problem. Only certain things in /usr/local would cause it to fail, correct?

Suggestion: if the db46 compile fails, then check whether /usr/local exists, and suggest temporarily renaming it as a possible workaround.

[vr@…]

Cc Me!

[domiman@…]

Cc Me!

[vr@…]

Since [60013] was only commited 15 hours ago and already this many responses indicates how severe an issue this is. Instead of having a blanket check for /usr/local why not check specific things db46 will look for? Or something along the lines of what dojo@ specifies

[blair (Blair Zajac)]

I can't look at this until sometime tomorrow. If somebody wants to send a patch in for the Portfile that finds all files in /usr/local/include/db* and /usr/local/lib/libdb* that will fail the build, then I can apply it.

[ben-macports@…]

Cc Me!

[jschwab@…]

Cc Me!

[blb@…]

The compilation error results just from having /usr/local/include/db.h (from a different version, 4.5.20 in my test), so checking for that is much safer (having libdb* in /usr/local/lib or db_cxx.h in /usr/local/include didn't interfere in my testing). Since the main issue is an incompatible bdb install in /usr/local, checking for db.h seems like a good idea since that'd definitely be a part of such an install.

Updated check in r60031.

[blair (Blair Zajac)]

Great, thanks a for doing the work to find out what exactly can cause an error and getting the test to fit that case.

Regards, Blair

[sjoerd@…]

Good to see all activity to solve the problem. However, moving db.h aside to db_aside.h during the upgrade, does not work in my case. The installation seems to progress, configure succeeds, but making seems to fail here:

cd ./classes && jar cf ../db.jar ./com/sleepycat
/bin/sh ./libtool --mode=compile /usr/bin/gcc-4.0 -c -O2 -arch i386  -I../dist/.. -I/opt/local/include -I/System/Library/Frameworks/JavaVM.framework/Versions/Current/Headers ../dist/../db_dump185/db_dump185.c
 /usr/bin/gcc-4.0 -c -I. -I../dist/.. -I/opt/local/include -I/System/Library/Frameworks/JavaVM.framework/Versions/Current/Headers -O2 -arch i386 -fno-strict-aliasing ../dist/../libdb_java/db_java_wrap.c -o db_java_wrap.o >/dev/null 2>&1
 /usr/bin/gcc-4.0 -c -O2 -arch i386 -I../dist/.. -I/opt/local/include -I/System/Library/Frameworks/JavaVM.framework/Versions/Current/Headers ../dist/../db_dump185/db_dump185.c  -fno-common -DPIC -o .libs/db_dump185.o
../dist/../db_dump185/db_dump185.c:23:16: error: db.h: No such file or directory

Moving /usr/local aside (which is a symlink to /usr, in my case), works, however.

[martin.eisenhardt@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Replying to sjoerd@…:

Good to see all activity to solve the problem. However, moving db.h aside to db_aside.h during the upgrade, does not work in my case. The installation seems to progress, configure succeeds, but making seems to fail here:
[snip]
Moving /usr/local aside (which is a symlink to /usr, in my case), works, however.

It's completely expected that just moving db.h aside would not be sufficient. You'll note the error message the port displays doesn't suggest this would work. You would need to move all parts of BerkeleyDB aside, including its headers and libraries. Moving the entirety of /usr/local is an easy way to be sure you move everything aside.

Please remember that it is not supported to have anything in /usr/local while using MacPorts, for exactly the reasons explored above in this ticket. It causes too many problems. If you can get it to work, great, but we are not here to provide help with that.

P.S: It is an incredibly bad idea to have /usr/local be a symlink to /usr. /usr is for things installed by the OS vendor (e.g. Apple). /usr/local is historically for things installed by the sysadmin (e.g. you). Don't mix these up, and again, for people using MacPorts, please do not install anything in /usr/local.

[mjhsieh@…]

Cc Me!

[peter.hillerstrom+macports@…]

Replying to matteo.corti@…:

Sorry? Moving /usr/local is not a solution on a production system where the directory is actually used. And why on earth should the build process need to "own/delete/modify" /usr/local? Matteo

I had this problem too, and I was first just as perplexed by the error message.
The next day I realized there was a brew installed berkeley-db in /usr/local.
I removed it, and hey presto everything works again!