port "cask" -- installing prebuilt binaries

[Mark Anderson]

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 <mark at 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 <emer at 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 <emer at emer.net>
> Find me on LinkedIn <https://www.linkedin.com/in/markemer/>
>
>
> On Sun, Dec 13, 2020 at 4:30 PM Nils Breunese <nils at breun.nl> wrote:
>
>> 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 <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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20201213/72e6eab8/attachment.htm>