> On Jul 27, 2016, at 8:26 AM, [email protected] wrote: > > Hi Ryan, > > >> On Jul 26, 2016, at 10:09 PM, Ryan Schmidt <[email protected]> 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. > > In my mind, the existing and largely useless “platform" variable should be > re-purposed and used for this purpose. It currently usually says “darwin” but > that could be expanded for each version of MacOS. > > To implement this, I think the default value in base should be changed to the > following for the next version of Macports for Sierra: > > platforms tiger leopard snowleopard lion mountainlion mavericks yosemite > elcapitan sierra > > Then we remove the “platform” variable from all Portfiles when we release the > new version of base. For ports that cannot build on, for example, lion the > Portfile’s platforms variable can either be overridden as such: > > platforms tiger leopard snowleopard mountainlion mavericks yosemite elcapitan > sierra > > or we expand base to allow a construct like: > > platforms-remove lion > > Or maybe this functionality already exists? > > For each new version of MacOS, we need to release a new version of base > anyway. That version of base will get the new MacOS version added to the > default “platforms” variable… > > platforms tiger leopard snowleopard mountainlion mavericks yosemite elcapitan > sierra sequoia > > For the libc++ issue, we simply add a keyword: > > requires_libc++ yes > > The p5-graveyard port(s) can set the platforms variable to blank.
Your suggestion seems like a variation of my "third possibility", which has the disadvantages that every new reason why a port might not be installable would need a new variable introduced in MacPorts base and a new release of MacPorts base. What about ports that need the user to install Java first? What about ports that need the user to download a file manually first (for example oracle-instantclient which requires users to agree to a license agreement before downloading distfiles)? Your idea for the p5-graveyard and similar ports to clear the platforms variable to indicate the port is not installable is clever, but wouldn't it be clearer to just call the variable "installable", which the port could set using any logic it requires, or to put such logic in a preflight phase? Your idea to use string names for each version of macOS has the problem that it means a ton of updates have to happen each time a new version of macOS is released, which is annually now. Most ports that have macOS version restrictions either build only on old systems (your suggestion would work well for them), or only on new systems (your suggestion works less well there because e.g. when Sierra comes out, all those ports need "sierra" added). A better implementation would let the port indicate that a port builds on macOS 10.X or older, or macOS 10.Y or newer. This is what those ports currently do, by checking os.major. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
