#19049: port activation fails with "Error: port activate failed: Not a directory" --------------------------------------+------------------------------------- Reporter: julio.lopez@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: base | Version: 1.7.0 Keywords: | Port: --------------------------------------+------------------------------------- The way symbolic links to directories are handled in the registry's file map causes failed installation for various ports. Examples are reported in #16068, #18878, #18380, #16599, #17404 among others. Besides the failed installation, the registry and the file map are left in an inconsistent state. The packages are said to be installed, however their contents are not added to the file map and not all the files are appropriately installed. There are workarounds that the port maintainers have put in place for some of the problems. Since this issue is causing bugs in many packages, it'd be desirable if this is handled at the port base level, perhaps in the registry or the file map. Also, it'd be a good idea to include in the documentation a clear explanation and a recommendation for the maintainers about the rule used to handle symbolic links to directories. The specific problem is that a package A may create a symlink to a directory where some of it's files are installed. When a different package B tries to add a file in a directory where the aforementioned symlink is in the path, then the installation fails with: {{{ DEBUG: Not a directory while executing "filemap set file_map $file $port" (procedure "receipt_flat::register_file" line 11) invoked from within "${macports::registry.format}::register_file $file $port" (procedure "registry::register_file" line 3) invoked from within "registry::register_file $file $name" (procedure "portimage::activate" line 65) invoked from within "portimage::activate $portname [composite_version $portversion [array get variations]] [array get options]" Error: port activate failed: Not a directory }}} For example, in the situation reported in #16068, python25 (e.g., @2.5.4_0) creates the following symbolic link: {{{ $ pwd /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib $ ls -l total 8 lrwxr-xr-x 1 root admin 24 Mar 13 11:41 python2.5 -> /opt/local/lib/python2.5 }}} The py25-pyqt4 port tries to add a file under: {{{ /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5 /site-packages/PyQt4/__init__.py }}} However, this fails because the link created by python25 is now in the file map and it does not correspond to a directory. The following excerpt from ${prefix}/var/macports/sources/rsync.macports.org/release/base/src/pextlib1.0/filemap.c shows where the test is performed and the taken action. The Set function (in filemap.c) is in the code path for the following TCL statement: {{{ filemap set filemapVarName path value }}} {{{ int Set(SNode** ioRoot, const char* inPath, const char* inValue) { int theResult = 0; ... if (theCurrentChar == '/') { if (theSubnode->fNodeType != kNode) { theResult = ENOTDIR; break; } ... }}} I hope this helps. Also, it'd be desirable to have command line tools (e.g., portadmin <command>) to test the integrity of the file map and the registry and be able to rebuild or fix an inconsistent file map. -- Ticket URL: <http://trac.macports.org/ticket/19049> MacPorts <http://www.macports.org/> Ports system for Mac OS