I like the idea of a separate thing like cask, (if only in labeling) but we don't always need it/shouldn't use it exclusively.
Like maybe for restrictive non-free stuff like Chrome a different mode makes sense, but with iTerm, I'm just trying to allow install on <10.15 and knowing the iTerm guy, pretty soon, less than 11.0 Maybe just: ---> iTerm2 is only available via binary on this system, source is available on 10.15+ ---> Chrome is only available via binary I'm not suggesting a Chrome port BTW, it's just the first thing I thought of since I'm using it right this second to send this. —Mark _______________________ Mark E. Anderson <m...@macports.org> MacPorts Trac WikiPage <https://trac.macports.org/wiki/mark> GitHub Profile <https://github.com/markemer> On Sun, Dec 13, 2020 at 4:42 PM Mark Anderson <e...@emer.net> wrote: > I like the idea of a separate thing like cask, (if only in labeling) but > we don't always need it/shouldn't use it exclusively. > > Like maybe for restrictive non-free stuff like Chrome a different mode > makes sense, but with iTerm, I'm just trying to allow install on <10.15 and > knowing the iTerm guy, pretty soon, less than 11.0 > > Maybe just: > ---> iTerm2 is only available via binary on this system, source is > available on 10.15+ > > ---> Chrome is only available via binary > > I'm not suggesting a Chrome port BTW, it's just the first thing I thought > of since I'm using it right this second to send this. > > > Thanks, > —Mark > _______________________ > Mark E. Anderson <e...@emer.net> > Find me on LinkedIn <https://www.linkedin.com/in/markemer/> > > > On Sun, Dec 13, 2020 at 4:30 PM Nils Breunese <n...@breun.nl> wrote: > >> Ken Cunningham <ken.cunningham.web...@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 >> <https://lists.macports.org/mailman/listinfo/macports-dev>> >> 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. >> >
