[MacPorts] #15937: port deactivate is a bit blood-thirsty (acts like it would delete /)
#15937: port deactivate is a bit blood-thirsty (acts like it would delete /) --------------------------------+------------------------------------------- Reporter: stephen@xemacs.org | Owner: macports-tickets@lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 1.7.0 Keywords: | --------------------------------+------------------------------------------- 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 }}} -- Ticket URL: <http://trac.macports.org/ticket/15937> MacPorts <http://www.macports.org/> Ports system for Mac OS
#15937: port deactivate is a bit blood-thirsty (acts like it would delete /) ---------------------------------+------------------------------------------ Reporter: stephen@xemacs.org | Owner: macports-tickets@lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: MacPorts base bugs Component: base | Version: 1.7.0 Resolution: | Keywords: ---------------------------------+------------------------------------------ Changes (by jmr@macports.org): * milestone: => MacPorts base bugs -- Ticket URL: <http://trac.macports.org/ticket/15937#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS
#15937: port deactivate is a bit blood-thirsty (acts like it would delete /) ---------------------------------+------------------------------------------ Reporter: stephen@xemacs.org | Owner: macports-tickets@lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: MacPorts base bugs Component: base | Version: 1.7.0 Resolution: | Keywords: ---------------------------------+------------------------------------------ Changes (by ryandesign@macports.org): * cc: ryandesign@macports.org (added) Comment: Maybe it should go up the directory tree only until it hits ${prefix}, not until it hits /. -- Ticket URL: <http://trac.macports.org/ticket/15937#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS
#15937: port deactivate is a bit blood-thirsty (acts like it would delete /) ---------------------------------+------------------------------------------ Reporter: stephen@xemacs.org | Owner: macports-tickets@lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: MacPorts base bugs Component: base | Version: 1.7.0 Resolution: | Keywords: ---------------------------------+------------------------------------------ Changes (by raimue@macports.org): * cc: raimue@macports.org (added) Comment: 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. -- Ticket URL: <http://trac.macports.org/ticket/15937#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS
#15937: port deactivate is a bit blood-thirsty (acts like it would delete /) ---------------------------------+------------------------------------------ Reporter: stephen@xemacs.org | Owner: macports-tickets@lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: MacPorts base bugs Component: base | Version: 1.7.0 Resolution: | Keywords: ---------------------------------+------------------------------------------ Comment (by ryandesign@macports.org): Replying to [comment:3 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. -- Ticket URL: <http://trac.macports.org/ticket/15937#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS
#15937: port deactivate is a bit blood-thirsty (acts like it would delete /) ---------------------------------+------------------------------------------ Reporter: stephen@xemacs.org | Owner: macports-tickets@lists.macosforge.org Type: defect | Status: closed Priority: Normal | Milestone: MacPorts base bugs Component: base | Version: 1.7.0 Resolution: wontfix | Keywords: ---------------------------------+------------------------------------------ Changes (by raimue@macports.org): * status: new => closed * resolution: => wontfix Comment: Replying to [comment:4 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. -- Ticket URL: <http://trac.macports.org/ticket/15937#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS
participants (1)
-
MacPorts