> On Jul 28, 2016, at 8:36 AM, [email protected] wrote: > > >> On Jul 27, 2016, at 6:19 PM, Ryan Schmidt <[email protected]> wrote: >> >> 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. > > We already need to release a new version of base for Sierra. I am suggesting > we deploy these changes then. > > >> 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)? > > Yes, so some kind of pre-fetch argument or new variables are needed for those > cases. Given your argument about clear intent (which I completely agree with > in general), I think that new keywords should be created for each case where > possible. > > requires_java yes > > That has the added complication of having base then determine if java is > indeed installed which can differ per version of MacOS. > > The oracle-instantclient example is singular and thus should require custom > code in the Portfile such as in a pre-fetch phase as you suggest.
But I'm specifically not advocating for code in a pre-fetch phase, which is what we already do now in many places, because I want to know before the fetch phase runs and before dependencies are installed whether the port can be installed or not. I am advocating for a new preflight phase that runs before dependencies are computed into which a port could put logic to decide whether it is installable or not. I'm concerned about expending development effort on building new variables such as "requires_java" when a generic solution that can be used by ports having unusual requirements is still needed. Why not use the generic solution everywhere? >> 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? > > I don’t have a problem with a new “installable” keyword. However clearing the > platforms variable and adding a comment for the few ports like p5-graveyard > seems reasonable to me and does not require more work. It requires work to change to MacPorts base to do something with the platforms variable, which it currently does not do. >> 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. > > Only ports that manually override the platforms variable would be required to > be updated for any new OS. Yes, I understand. The default would be to be installable on all platforms. > However, to be clear, one should only do that for ports that only run on an > old version of MacOS. So mostly Portfiles (that need to use this > functionality) should use platforms_remove which would then automatically > include the new OS in base. Usually we are removing old/unsupported OS > versions. > > platforms_remove tiger leopard snowleopard > > So any correctly written Portfile would not need any changes for every new > version of MacOS. That's a good point, if portfile developers remember to do it that way. That resolves my objection. The command (which already exists) is "platforms-delete". All "options" (the special variables MacPorts knows about that you can set in portfiles without using the "set" command) support the -append, -delete, -replace and -stdsed modifiers. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
