On Jul 27, 2016, at 8:24 PM, Craig Treleaven wrote: > On Jul 27, 2016, at 12:09 AM, Ryan Schmidt wrote: > >> I would like MacPorts to be extended so that it can be determined in >> advance, from the command line, before running "port install", whether a >> port can be installed (barring unexpected build failures and bugs). >> Currently, MacPorts assumes any port can be installed on any system, which >> is not the case. Many ports cannot be built on certain versions of macOS. >> Some require libc++. Some require dependencies to be installed with a >> nondefault variant. Some have other requirements. Some ports, like >> p5-graveyard or other ports that serve as placeholders designed to inform >> the user of the discontinuation of a port, are designed to fail. Being able >> to determine in advance whether a port is supposed to be installable will >> let us skip those ports when triggering builds on the buildbot. This will >> cut down on unnecessary work performed by the buildbot, and will avoid >> unnecessary emails sent to maintainers who already know the port will fail >> in those circumstances. >> >> How can we accomplish this? We currently use "return -code error" to trigger >> these kinds of error messages from ports, but we do so within a phase, such >> as pre-configure or pre-fetch, but that means that code doesn't run until >> those phases are running, and I want to know before those phases run, indeed >> even before dependencies are calculated and installed. >> >> 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. >> >> Another possible solution could be to define a new Boolean variable >> "installable" to indicate if the port is installable, which would default to >> "yes". If a port sets this to "no", MacPorts could print a generic failure >> message. There could be a second variable which the port developer could set >> to a custom failure message. >> >> A third possibility could be to codify each of the reasons why a build might >> fail, and introduce new variables for each reason. For example, a variable >> to indicate the supported C++ libraries, or a variable to indicate the >> supported macOS versions. There might be some advantage to this, in that it >> could be used to programmatically answer questions like what C++ libraries >> or macOS versions a port supports, but it is the least flexible and most >> complicated solution. > > Could I submit that there may be two issues being conflated? > > 1) Some ports are known to crap out on our buildbots. > > 2) It is known that some ports cannot be installed on particular system > configurations. > > For 1), I think we should simply add a keyword to the portfile that tells the > buildbot not to attempt to build this port. “mp_buildbot_skip” or some such. > Add this to the p5-graveyard and all other ports that we know the buildbot > cannot or should not attempt to build. > > For 2), we already have a series of tools that provide information about the > environment and let the port do the right thing. I like the idea of a > preflight phase—a number of ports ‘abuse’ the pre-fetch phase to essentially > do this. However I’m not sure how prevalent or serious the problem is in 2) > that we’re trying to solve.
The buildbot should be a tool that helps developers identify when a port fails to build, so that the developers can fix it. I don't want to inundate developers with emails about build failures that they already know will happen. This will cause developers to ignore buildbot emails, and I don't want that. I oppose making changes to portfiles that are specific to the buildbot. The buildbot is not special. It is just another computer with a MacPorts installation. Anything the buildbot needs, users need too. > (And there is the -y flag to ‘dry-run’ the installation.) Yes... Is there a way I'm not seeing for the -y flag to be used to accomplish what I want? _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
