<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr">Ken Cunningham <ken.cunningham.webuse@gmail.com> wrote:</div><div dir="ltr"><br></div><blockquote type="cite"><div dir="ltr"><p>
</p><blockquote type="cite">
<pre style="white-space: pre-wrap; color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">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 <<a href="https://lists.macports.org/mailman/listinfo/macports-dev">mark at macports.org</a>>
MacPorts Trac WikiPage <<a href="https://trac.macports.org/wiki/mark">https://trac.macports.org/wiki/mark</a>>
GitHub Profile <<a href="https://github.com/markemer">https://github.com/markemer</a>>
</pre>
</blockquote>
<p></p>
<p><br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<p>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.</p></div></blockquote><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></span></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">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.</span></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></span></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">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.</span></div><br><div>Nils.</div></body></html>