Determine before installation whether a port can be installed

Mojca Miklavec mojca at
Wed Aug 10 08:44:18 PDT 2016

On 27 July 2016 at 06:09, Ryan Schmidt wrote:
> One solution that occurs to me is to define a new "preflight" phase, to be run before dependencies are computed. Ports can override that phase and do whatever checks they need and exit with "return -code error" if needed. This seems like the most straightforward and flexible solution.

Independent of whether or not this phase would be used for this
purpose, I would find it useful.

At the moment there is no way to "just do something (not even useful)"
with the port. I can run "port fetch", but then this would fetch the
distfile even if the binary package already exists and fetching could
be skipped, so even fetching is "wasting resources".

The problem (that could be solved on both buildbot and user
installation if we had such a phase) is that currently running "sudo
port install <some-broken-port>" would happily install all
dependencies even if the port itself cannot be installed.

On the buildbot we could run
    sudo port preflight portname
    # then install dependencies
    sudo port install portname
and if the first one fails, there's no need to continue.

For regular users this step could also prevent installing dependencies
if it could be executed "cheap enough".

If I want to bring the port to a state when main.log is created, so
that it could be retrieved with "port logfile <portname>" without
actually trying to fetch/extract/configure anything, this is probably
not possible at the moment.

Given how much trickery is currently already present in the buildbot
setup, a failing preflight phase could be sufficient to filter out
false negatives and avoid sending emails about (knowingly) broken

I'm not saying that we shouldn't implement better ways to signal
obsolete and known-to-be-broken ports. I'm just saying that
implementing some initial phase (that doesn't do anything) would be


More information about the macports-dev mailing list