Determine before installation whether a port can be installed

[Ryan Schmidt]

> On Jul 28, 2016, at 8:36 AM, mf2k at macports.org wrote:
> 
> 
>> On Jul 27, 2016, at 6:19 PM, Ryan Schmidt <ryandesign at macports.org> 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.