port "cask" -- installing prebuilt binaries

Nils Breunese nils at breun.nl
Sun Dec 13 21:29:51 UTC 2020


Ken Cunningham <ken.cunningham.webuse at gmail.com> wrote:

>> 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>
>> MacPorts Trac WikiPage <https://trac.macports.org/wiki/mark>
>> GitHub Profile <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 unresolved.
> 

Why is having binary ports without a special indicator a problem? MacPorts has already has ports that use upstream binaries, mostly for ports that are either impossible to build from source (Google Cloud SDK source is not available AFAIK for instance), or very hard/time-consuming (OpenJDK for instance) to build. I maintain a couple of ports like these and they don’t have a specific name or variant or anything indicating that they use upstream binaries and I don’t see a problem with that really. If someone would ever decide it’s a good idea to switch to building OpenJDK from source via a Portfile, that could just be transparently done without any users having to switch to a different port name or variant, and that seems fine to me.

It might even make sense for some ports (like iTerm2 perhaps?) to build from source on macOS versions for which that is feasible, and use an upstream binary on OS versions for which it isn’t.

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


More information about the macports-dev mailing list