[MacPorts] #50233: port upgrade --force shouldn't uninstall if no permission was given to install a missing dependency

[MacPorts]

#50233: port upgrade --force shouldn't uninstall if no permission was given to
install a missing dependency
--------------------------+--------------------------------
  Reporter:  rjvbertin@…  |      Owner:  macports-tickets@…
      Type:  defect       |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  base         |    Version:  2.3.4
Resolution:               |   Keywords:
      Port:               |
--------------------------+--------------------------------

Old description:

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

New description:

 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
 .

--

Comment (by ryandesign@…):

 I agree that if you answer "no" to the "Continue?" prompt, MacPorts should
 abort and not do anything.

-- 
Ticket URL: <https://trac.macports.org/ticket/50233#comment:1>
MacPorts <https://www.macports.org/>
Ports system for OS X