Deactivate does not fully remove (some) empty directories

[michaelld@…]

In getting Stellarium.app to install correctly (checked in in [68848]), I did a lot of deactivating (via uninstall) and installing of that port while the Finder window for /Applications/MacPorts/ was open. After each uninstall I could see that Stellarium.app was still there, but no longer had an icon or Finder info associated with it. I can verify via an X11 terminal window that the basic directory structure was not actually removed -- just the files inside it were. The resulting top-level file (Stellarium.app) remained and cannot be used -- there is no executable in it, nor Info files describing it, just empty directories (or, directories of directories). Installing a new revision over these directories worked without issue, but after a deactivate the resulting top-level Stellarium.app obviously doesn't work.

I then tried deactivate with LaTeXiT and the same thing happens -- so I don't think this issue is specific to Stellarium; it seems to be a greater issue. While doing 'deactivate' with debug printing on, I can see that Port is, at least sometimes, checking whether or not the directory is empty, but it seems as though not all directories are checked. I can submit "port -d" if desired, but I'm sure whoever looks into this can do that too.

What I'm asking for is to fix checking whether a directory is empty during deactivate -- or, fix the list of what to deactivate & check for being empty, if that's the issue.

[jmr@…]

Just tried this with Lingon and it seems fine. My guess would be that the directories aren't actually empty (.DS_Store or whatever).

[michaelld@…]

Doesn't seem to be extra files; maybe it's the ordering in which items are removed? Appending listings for Stellariom.app just to show it.

[michaelld@…]

results of command 'port -d deactivate stellarium' when stellarium is active

[michaelld@…]

results of command 'port -d activate stellarium' when stellarium is not active

[michaelld@…]

result of command 'cd /Applications/MacPorts && ls -lAR Stellarium.app' when stellarium is active

[michaelld@…]

result of command 'cd /Applications/MacPorts && ls -lAR Stellarium.app' when stellarium is not active

[michaelld@…]

Forgot to mention, if it make any difference: 10.5.8 Intel latest (except Safari 5.0) on a MacBook Pro 17" early 2009, XCode 3.1.3, MacPorts 1.9.0 .

[michaelld@…]

I am happy look into this issue myself, but I truly have no idea where to start since I deal with Portfile-s, not with 'port' functionality itself. Since it's not clear where this issue lies, I'd be tempted to look at the 'port' source first instead of messing further with the Portfile-s. If you / anyone wants to point me towards the source, I'll see what I can figure out.

[jmr@…]

What exactly is the relationship between /opt/local/Applications/MacPorts/Stellarium.app and /Applications/MacPorts/Stellarium.app here?

[michaelld@…]

Sorry, that might help: sudo ln -s /opt/local/Applications/MacPorts /Applications/MacPorts

[jmr@…]

And which one do you actually have configured as applications_dir?

[michaelld@…]

I'm not changing the applications_dir, so it is the default, which I presume is '/opt/local/Applications/MacPorts'. The symlink is just for my convenience, and otherwise shouldn't change how files are read or written.

[jmr@…]

Of course it shouldn't, but clearly it is. The default applications_dir is /Applications/MacPorts. Please check what your macports.conf actually says.

[jmr@…]

Please try this patch as well.

[michaelld@…]

I haven't touched the macports.conf file, but I had the default incorrect. Here's what the file says:

# Directory containing Applications from ports.
applications_dir        /Applications/MacPorts

So, possibly, my symlink was interfering with the expected behavior. I'll try your patch later tonight.

[jmr@…]

OK, so I would consider that a slightly odd setup, but we should still handle it correctly of course. Basically the problem is that that file normalize doesn't resolve symlinks in the version of Tcl shipped with 10.5 and earlier. We currently work around that for the parent directories of each file registered to the port, since otherwise we could end up deleting intermediate symlinks. It's OK to leave the path as-is when deleting the file itself, except it can mess up the sorting of the file list as seen here.

[michaelld@…]

Yes, that patch works for me.

[jmr@…]

OK, committed in r68864.

[michaelld@…]

Thanks!