port deactivate is a bit blood-thirsty (acts like it would delete /)

[yaseppochi (Stephen J. Turnbull)]

While I can't come up with a scenario where "something wicked" could actually happen, since "FOO is not empty" seems to imply "... so I won't remove it", the following output from "port -d deactivate apr" was a bit disconcerting:

DEBUG: /opt/local/include/apr-1 is not empty
DEBUG: /opt/local/include is not empty
DEBUG: deactivating file: /opt/local/bin/apr-1-config
DEBUG: /opt/local/bin is not empty
DEBUG: /opt/local is not empty
DEBUG: /opt is not empty
DEBUG: / is not empty

[ryandesign (Ryan Carsten Schmidt)]

Maybe it should go up the directory tree only until it hits ${prefix}, not until it hits /.

[raimue (Rainer Müller)]

I did not look at the code yet, but we do not prevent files being installed anywhere outside the prefix. port only issues a warning if this happens.

Also, some files reside intentionally in /Applications and /Library, so I assume stopping at ${prefix} would not deactivate them correctly.

I would say port deactivate should only prune empty directories if it is in our mtree.

[ryandesign (Ryan Carsten Schmidt)]

Replying to raimue@macports.org:

I did not look at the code yet, but we do not prevent files being installed anywhere outside the prefix. port only issues a warning if this happens.

Also, some files reside intentionally in /Applications and /Library, so I assume stopping at ${prefix} would not deactivate them correctly.

You're right about that. We should not stop at ${prefix} as I pondered earlier. So we shouldn't change anything there.

I would say port deactivate should only prune empty directories if it is in our mtree.

Actually I wouldn't even change that. A port might install a directory in, say, /Applications/MacPorts. For example for minivmac 3 I want to make a directory /Applications/MacPorts/Mini vMac. And lesstif installs a directory in ${x11prefix}/LessTif. MacPorts should remove these directories if these ports are uninstalled.

So since I haven't heard of any detriment being caused by the code the way it is, and changing it will cause problems as detailed above, I would say we should close this as wontfix.

[raimue (Rainer Müller)]

Replying to ryandesign@macports.org:

Actually I wouldn't even change that. A port might install a directory in, say, /Applications/MacPorts. For example for minivmac 3 I want to make a directory /Applications/MacPorts/Mini vMac. And lesstif installs a directory in ${x11prefix}/LessTif. MacPorts should remove these directories if these ports are uninstalled.

/Applications/MacPorts is in our mtree, ${x11prefix} is not. So lesstif would not get uninstalled correctly if we would change that. Also there would be no automatic cleanup if a port accidentally installs files outside the mtree.

So since I haven't heard of any detriment being caused by the code the way it is, and changing it will cause problems as detailed above, I would say we should close this as wontfix.

I agree. Closing as wontfix.

[tobypeterson]

Milestone MacPorts base bugs deleted