Opened 15 years ago

Closed 15 years ago

Last modified 12 years ago

#22291 closed defect (fixed)

db46 4.6.21_6 Extracting - failed

Reported by: senz@… Owned by: blair (Blair Zajac)
Priority: Normal Milestone:
Component: ports Version: 1.8.1
Keywords: Cc: matteocorti (Matteo Corti), mirimiri66@…, alex+mp@…, chris@…, dershow, macports@…, vr@…, domiman@…, ben-macports@…, jschwab@…, martin.eisenhardt@…, mjhsieh@…
Port: db46

Description

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

Change History (34)

comment:1 Changed 15 years ago by matteocorti (Matteo Corti)

Cc: matteo.corti@… added

Cc Me!

comment:2 Changed 15 years ago by jmroot (Joshua Root)

Resolution: wontfix
Status: newclosed

Do what the error message says.

comment:3 Changed 15 years ago by 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

comment:4 Changed 15 years ago by 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.

comment:5 Changed 15 years ago by 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.

comment:6 Changed 15 years ago by mirimiri66@…

Cc: mirimiri66@… added

Cc Me!

comment:7 Changed 15 years ago by songzw@…

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

comment:8 in reply to:  1 Changed 15 years ago by 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.

comment:9 Changed 15 years ago by alex+mp@…

Cc: alex+mp@… added

Cc Me!

comment:10 Changed 15 years ago by 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 ...

comment:11 Changed 15 years ago by 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 } {

comment:12 Changed 15 years ago by mf2k (Frank Schima)

Resolution: wontfix
Status: closedreopened

comment:13 Changed 15 years ago by mf2k (Frank Schima)

Owner: changed from macports-tickets@… to blair@…
Status: reopenednew

comment:14 Changed 15 years ago by mf2k (Frank Schima)

Type: updatedefect

comment:15 Changed 15 years ago by chris@…

Cc: chris@… added

Cc Me!

comment:16 Changed 15 years ago by 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.

comment:17 Changed 15 years ago by 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.

comment:18 Changed 15 years ago by dershow

Cc: dersh@… added

Cc Me!

comment:19 Changed 15 years ago by 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.

comment:20 Changed 15 years ago by macports@…

Cc: macports@… added

Cc Me!

comment:21 Changed 15 years ago by 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.

comment:22 Changed 15 years ago by vr@…

Cc: vr@… added

Cc Me!

comment:23 Changed 15 years ago by domiman@…

Cc: domiman@… added

Cc Me!

comment:24 Changed 15 years ago by 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

comment:25 Changed 15 years ago by 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.

comment:26 Changed 15 years ago by ben-macports@…

Cc: ben-macports@… added

Cc Me!

comment:27 Changed 15 years ago by jschwab@…

Cc: jschwab@… added

Cc Me!

comment:28 Changed 15 years ago by blb@…

Resolution: fixed
Status: newclosed

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.

comment:29 Changed 15 years ago by 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

comment:30 Changed 15 years ago by 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.

comment:31 Changed 15 years ago by martin.eisenhardt@…

Cc: martin.eisenhardt@… added

Cc Me!

comment:32 in reply to:  30 Changed 15 years ago by 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.

comment:33 Changed 15 years ago by mjhsieh@…

Cc: mjhsieh@… added

Cc Me!

comment:34 in reply to:  3 Changed 12 years ago by 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!

Note: See TracTickets for help on using tickets.