port "cask" -- installing prebuilt binaries

Ken Cunningham ken.cunningham.webuse at gmail.com
Sun Dec 13 20:15:15 UTC 2020

> So, I'm looking to install iTerm2 for old systems from binary as building
> is becoming increasingly impossible - have we come to a consensus on any of
> this?
> —Mark
> _______________________
> Mark E. Anderson <mark at macports.org  <https://lists.macports.org/mailman/listinfo/macports-dev>>
> MacPorts Trac WikiPage <https://trac.macports.org/wiki/mark  <https://trac.macports.org/wiki/mark>>
> GitHub Profile <https://github.com/markemer  <https://github.com/markemer>>

I continue to believe that in general trying to shoehorn "cask" binary 
installs as some variant of a port that is generally meant to build from 
source is a recipe for nothing but endless trouble. Homebrew has a 
completely different subsystem for cask installs that makes it really 
clear what you are getting, and this is very desirable, I agree.

IMHO binary-only install port should have some clearly recognizable port 
name that does not cause confusion about what it is, and does not 
obscure or trample a port's existing variants (which a "prebuilt" or 
other similar variant name would do, if there were other variants). We 
have port name distinctions for a great many ports in MacPorts now (the 
perl, python, php, etc, etc, etc port families, for example). Having a 
naming family for binary-only ports is No Big Deal.

Chris has suggested a category inclusion, which is pure and uses 
macports unique functionality, but IMHO is unrecognizable for 99.9999% 
of users who would never notice that a given port is added to a certain 
category or subcategory.

But we should resolve this, as many people want it, whatever is decided 
by the managers, who so far have expressed no opinion, ergo it is 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20201213/ed9dd5ae/attachment.htm>

More information about the macports-dev mailing list