> 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. > 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. > 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. 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. Cheers! Frank
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
