Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#15937 closed defect (wontfix)

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

Reported by: yaseppochi (Stephen J. Turnbull) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: base Version: 1.7.0
Keywords: Cc: ryandesign (Ryan Schmidt), raimue (Rainer Müller)
Port:

Description

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

Change History (7)

comment:1 Changed 12 years ago by jmroot (Joshua Root)

Milestone: MacPorts base bugs

comment:2 Changed 12 years ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… added

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

comment:3 Changed 12 years ago by raimue (Rainer Müller)

Cc: raimue@… added

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.

comment:4 in reply to:  3 ; Changed 12 years ago by ryandesign (Ryan 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.

comment:5 in reply to:  4 Changed 12 years ago by raimue (Rainer Müller)

Resolution: wontfix
Status: newclosed

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.

comment:6 Changed 12 years ago by tobypeterson

Milestone: MacPorts base bugsMacPorts Future

Milestone MacPorts base bugs deleted

comment:7 Changed 11 years ago by jmroot (Joshua Root)

Milestone: MacPorts Future
Note: See TracTickets for help on using tickets.