[MacPorts] #62621: mpbb takes too long to install dependencies

[MacPorts]

#62621: mpbb takes too long to install dependencies
----------------------------+---------------------
  Reporter:  ryandesign     |      Owner:  admin@…
      Type:  defect         |     Status:  new
  Priority:  Normal         |  Milestone:
 Component:  buildbot/mpbb  |    Version:
Resolution:                 |   Keywords:
      Port:                 |
----------------------------+---------------------

Comment (by ryandesign):

 These are two somewhat different cases. On the buildbot we keep all ports
 installed, and mpbb-install-dependencies prints "Already installed,
 nothing to do" and does nothing more for each direct dependency that's
 already installed. But on the CI build machines no ports are installed to
 begin with so it goes through the whole process of fetching the archive,
 installing and activating it (and its dependencies), then deactivating
 everything, for each direct dependency.

 I expect the reason why it deactivates everything between dependencies is
 so that if any dependency was not already built, then that dependency will
 build from source with a clean slate, without any other random ports
 activated that might affect its build. However since #60935 was
 implemented, that should never be the case anymore. Packages for all
 dependencies should already exist by the time any build is attempted. So
 ''maybe'' we can streamline mpbb-install-dependencies so that if archive
 fetch fails, the entire build fails.

 That might be too simple though. CI build machines sometimes lose access
 to the private packages server; in that case, it would be better to take
 extra time to build those nondistributable dependencies again in the PR
 rather than fail the PR. We could move `"${option_prefix}/bin/port" -fp
 deactivate active` so that it is only run right before we install a
 dependency from source, rather than right after installing any dependency.
 We should be able to determine whether fetching the archive succeeded to
 decide whether or not to then deactivate active. And if any dependency was
 built from source, we might have to deactivate again at the end of
 installing all dependencies to ensure none of the dependencies' build
 dependencies are present for the main port build.

 It would be even better if we could deactivate just the ports that should
 not be active for the next build, rather than deactivate everything. For
 example, looking at the dependency list from auto-multiple-choice-devel
 above, suppose we were able to install and activate gperf, libiconv, and
 ncurses from binaries, and then the gettext package couldn't be fetched
 and needed to be built from source. Rather than deactivating gperf,
 libiconv, and ncurses, and then building gettext from source, which would
 reactivate libiconv and ncurses again, it would be better if we could just
 deactivate gperf. But I don't think we have a way to do that yet.

-- 
Ticket URL: <https://trac.macports.org/ticket/62621#comment:5>
MacPorts <https://www.macports.org/>
Ports system for macOS