New Ticket     Wiki     Browse Source     Timeline     Roadmap     Ticket Reports     Search

Ticket #15937 (closed defect: wontfix)

Opened 4 years ago

Last modified 2 years ago

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

Reported by: stephen@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: base Version: 1.7.0
Keywords: Cc: ryandesign@…, raimue@…
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

  Changed 4 years ago by jmr@…

  • milestone set to MacPorts base bugs

  Changed 4 years ago by ryandesign@…

  • cc ryandesign@… added

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

follow-up: ↓ 4   Changed 4 years ago by raimue@…

  • 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.

in reply to: ↑ 3 ; follow-up: ↓ 5   Changed 4 years ago by ryandesign@…

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.

in reply to: ↑ 4   Changed 4 years ago by raimue@…

  • status changed from new to closed
  • resolution set to wontfix

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.

  Changed 3 years ago by toby@…

  • milestone changed from MacPorts base bugs to MacPorts Future

Milestone MacPorts base bugs deleted

  Changed 2 years ago by jmr@…

  • milestone MacPorts Future deleted
Note: See TracTickets for help on using tickets.