Opened 9 years ago
Last modified 9 years ago
#50233 new defect
port upgrade --force shouldn't uninstall if no permission was given to install a missing dependency — at Version 1
Reported by: | RJVB (René Bertin) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | base | Version: | 2.3.4 |
Keywords: | Cc: | ||
Port: |
Description (last modified by ryandesign (Ryan Carsten Schmidt))
This is a rare situation, that gave rise to a port being uninstalled in error, I consider:
Given: a port "A" that has a build dependency on port "B1" which itself conflicts with port "B2". Once built, port "A" can co-exist with either "B1" or "B2"; in fact, "A" has a path-style *runtime* dependency on an executable provided by both B1 and B2 (path:bin/bb).
Scenario (leaving out sudo, and ignoring the reasons why I proceeded this way):
> port deactivate B2 > port activate B1 > port destroot A > port deactivate B1 > port activate B2 > port -nv upgrade --force A ---> Computing dependencies for A.. The following dependencies will be installed: B1 Continue? [Y/n]: n ---> Deactivating A @version ---> Uninstalling A @version ---> Cleaning A ---> Removing work directory for A ---> Computing dependencies for A.. The following dependencies will be installed: B1 Continue? [Y/n]: n ---> Scanning binaries for linking errors
I consider that the process should have been aborted when I first refused to install B1. One could also consider that
- the depends_build dependency should be ignored since the build process has been completed
- the depends_run dependency is satisfied by the presence of ${prefix}/bin/bb (provided by B2 at the time).
So in a sense there should be no missing dependency when doing an upgrade .
Change History (1)
comment:1 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
Description: | modified (diff) |
---|
Note: See
TracTickets for help on using
tickets.
I agree that if you answer "no" to the "Continue?" prompt, MacPorts should abort and not do anything.