Re: port "cask" -- installing prebuilt binaries

Another prime example for a cask port, but showing yet different issues, looks to be osxfuse. osxfuse is required for a number of other ports, but the current osxfuse port is three years out of date because it’s no long open source, and users need to use the upstream installer. For this one,

Re: port "cask" -- installing prebuilt binaries

> On Dec 24, 2020, at 10:58 AM, Jason Liu wrote: > > A more efficient method that overrides activate/deactivate and does not > needlessly de everything would seem useful. > > Since the dmg itself is a compressed archive, it would seem to make sense > that activate/deactivate would operate

Re: port "cask" -- installing prebuilt binaries

> > A more efficient method that overrides activate/deactivate and does not > needlessly de everything would seem useful. > Since the dmg itself is a compressed archive, it would seem to make sense that activate/deactivate would operate directly on the dmg, no? In other words, the distfile *is*

Re: port "cask" -- installing prebuilt binaries

I've been building a few of these "cask" installers for my own use. I'm finding using the normal port activate/deactivate process quite inefficient for this... For example, SageMath is a 1.5GB dmg, and is about 4GB installed. Downloading the dmg, decompressing it and copying the contents into

Re: port "cask" -- installing prebuilt binaries

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,

Re: port "cask" -- installing prebuilt binaries

Ken Cunningham 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 >> MacPorts Trac WikiPage

Re: port "cask" -- installing prebuilt binaries

So yeah - I think that a name and separate port is a good idea. I'm also on board for the category for the 0.0001% of us that would use it. maybe category: binary and binary-PortName like we do with like py38-something —Mark ___ Mark E. Anderson MacPorts Trac WikiPage

Re: port "cask" -- installing prebuilt binaries

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 https://lists.macports.org/mailman/listinfo/macports-dev>> MacPorts Trac WikiPage

Re: port "cask" -- installing prebuilt binaries

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 MacPorts Trac WikiPage GitHub Profile

Re: Supporting installing arbitrary port versions (was: Re: port "cask" -- installing prebuilt binaries)

> Just looking at your idea to distribute all portfile versions, let's start > with the fact that portfile syntax has evolved over time. > This is where portfile syntax itself can, and probably should, be versioned. Maybe by incrementing PortSystem? i.e. PortSystem 1.3, 1.4, 2.0, etc. Similar to

Re: Supporting installing arbitrary port versions (was: Re: port "cask" -- installing prebuilt binaries)

On Oct 3, 2020, at 06:05, Lothar Haeger wrote: >> It's because, besides being an unimaginably large amount of work in >> rearranging our code to do it, I have absolutely no idea how it would be >> accomplished without providing the user with unlimited opportunities to >> create broken

Re: port "cask" -- installing prebuilt binaries

Ok. So contenders for the metadata identifying non-buildable binary-only ports we have: name suffix (like the hs- ports had) category only variant as identifier We have spent far too long on this nonsense. Some admin pick one, then lets move on. K

Re: port "cask" -- installing prebuilt binaries

> Am 03.10.2020 um 03:00 schrieb Ryan Schmidt : > > Lothar, I agree with most of your reasoning for why a variant is a reasonable > choice for indicating a prebuilt binary. I am less concerned with how to > indicate prebuilt status than I am with whether we should do it at all. Interesting,

Re: port "cask" -- installing prebuilt binaries

Ryan, > Am 03.10.2020 um 03:00 schrieb Ryan Schmidt : > >> Just MacPorts did not implement it yet and when the necessity arose a >> seemingly simple workaround was chosen instead of solving the underlying >> problem. > > As for MacPorts, it's not that we haven't implemented it because we're

Re: port "cask" -- installing prebuilt binaries

Lothar, I agree with most of your reasoning for why a variant is a reasonable choice for indicating a prebuilt binary. I am less concerned with how to indicate prebuilt status than I am with whether we should do it at all. For ports that are not available any way other than prebuilt, I'm not

Re: port "cask" -- installing prebuilt binaries

> Am 02.10.2020 um 17:02 schrieb Ken Cunningham > : > > So this issue seems still active, but without a decided plan here, people are > just starting to PR their favourite approach, which is of course exactly what > we are tring to avoid. Ken, it's not "people", it's just me who provided

Re: port "cask" -- installing prebuilt binaries

> On Oct 2, 2020, at 8:02 AM, Ken Cunningham > wrote: > > Chris says put them in a category. Logical, but I don't know if most users > would note that when trying to install them, as it is not perhaps obvious > enough these are different beasts. Also, it it is decided to go ahead with the

Re: port "cask" -- installing prebuilt binaries

So this issue seems still active, but without a decided plan here, people are just starting to PR their favourite approach, which is of course exactly what we are tring to avoid. The idea of identifying them by a variant suffers from the fact that these are obviously not variants, they are

Re: port "cask" -- installing prebuilt binaries

> Am 15.08.2020 um 10:37 schrieb Lothar Haeger : > >> The variant name is: +prebuilt > > I like that name for its conciseness, lack of an underscore and correct > tense. :-) So here's an example how this could look like in real life: https://github.com/macports/macports-ports/pull/8503

Re: port "cask" -- installing prebuilt binaries

Doesn't the port `ghc` do exactly this? https://github.com/macports/macports-ports/blob/master/lang/ghc/Portfile#L31-L33 The variant name is: +prebuilt throwaway bootstrap compiler only, totally different issue

Re: port "cask" -- installing prebuilt binaries

> Am 15.08.2020 um 09:47 schrieb Eric F (iEFdev) : > > Doesn't the port `ghc` do exactly this? > https://github.com/macports/macports-ports/blob/master/lang/ghc/Portfile#L31-L33 > > Yes, looks like it does.

Re: port "cask" -- installing prebuilt binaries

On 8/15/20 8:48 , Lothar Haeger wrote: >> Am 15.08.2020 um 01:11 schrieb Ken Cunningham >> : >> >> so -- what would a user typing > Obviously that variant would conflict with all other variants, much like > +ruby21 conflicts with +ruby22. So the user would type > > sudo port -v install macvim

Re: port "cask" -- installing prebuilt binaries

On 2020-08-14 11:48 p.m., Lothar Haeger wrote: Am 15.08.2020 um 01:11 schrieb Ken Cunningham : so -- what would a user typing Obviously that variant would conflict with all other variants, much like +ruby21 conflicts with +ruby22. So the user would type sudo port -v install macvim

Re: port "cask" -- installing prebuilt binaries

> Am 15.08.2020 um 01:11 schrieb Ken Cunningham > : > > so -- what would a user typing Obviously that variant would conflict with all other variants, much like +ruby21 conflicts with +ruby22. So the user would type sudo port -v install macvim +prebuild_binary

Re: port "cask" -- installing prebuilt binaries

> On 14 Aug 2020, at 19:11, Ken Cunningham > wrote: > > so -- what would a user typing > > sudo port -v install macvim +prebuild_binary -huge +big +ruby25 +tcl +xim > > be expected to get? It's a total shambles. > They’d see the same thing they see if they tried to run: > sudo port

Re: port "cask" -- installing prebuilt binaries

I mean, you can maybe describe the “feature set” of the prebuilt binary in the variant description and forbid all the other variants… Can’t you? No doubt, with sufficient effort, we could take something inherently simple and make a complicated and undecipherable version of it. PS: Maybe

Re: port "cask" -- installing prebuilt binaries

I mean, you can maybe describe the “feature set” of the prebuilt binary in the variant description and forbid all the other variants… Can’t you? PS: Maybe “prebuilt_binary” is not the right wording since most of the ports can already be installed as “prebuilt_binary”. Maybe it should be something

Re: port "cask" -- installing prebuilt binaries

consider: $ port variants macvim Warning: port definitions are more than two weeks old, consider updating them by running 'port selfupdate'. MacVim has the variants:    big: Build big feature set * conflicts with huge    cscope: Enable source code browsing with cscope [+]huge: Build huge

Re: port "cask" -- installing prebuilt binaries

> Am 07.08.2020 um 01:13 schrieb Ken Cunningham > : > An example: let’s take the port MacVIM, which is ripe for this treatment. > > We can build and install the current macvim on some newer systems - let’s say > 10.12 to current. > > port -v install macvim gets you that. > > We will all

Re: port "cask" -- installing prebuilt binaries

On Aug 7, 2020, at 10:49, Ken Cunningham wrote: > By the way, for an SDK port, Gcenx has done one in an interesting way that > might be useful too. > > Well that's just my port with further modifications. When I

Re: port "cask" -- installing prebuilt binaries

OpenJDK is open source, so it can be built from source. However, it is quite a complex and lengthy build. As the maintainer of the openjdk* ports I decided to use the binaries provided by the AdoptOpenJDK (for the HotSpot VM and OpenJ9 VM based JDK’s) and GraalVM projects. I personally wouldn’t

Re: port "cask" -- installing prebuilt binaries

nope, variant is just wrong in all ways. K

Re: port "cask" -- installing prebuilt binaries

> On 7 Aug 2020, at 09:04, Ken Cunningham > wrote: > > If we use only category to mark as a binary port, what if we have a binary > port added (e.g. say lazarus) but then we later find out we can build that > port on some systems? Then we want the binary lazarus moved to > lazarus-binary,

Re: port "cask" -- installing prebuilt binaries

On 2020-08-07, at 12:10 AM, Ryan Schmidt wrote: > > > On Aug 6, 2020, at 21:20, Ruben Di Battista wrote: > >> If they've been built somewhere by the upstream developer, shouldn't we be >> able to build them too and hence instead of providing them as binaries we >> would fix the ports in

Re: port "cask" -- installing prebuilt binaries

A few more issues: Handling supported_archs in binary-only ports. What if binary comes only as a universal binary, but the user asks for only one arch? We want that one binary to satisfy all the situations it can. Handling universal requests. What if user asks for universal? If binary comes

Re: port "cask" -- installing prebuilt binaries

yes, it's variant names that can't have + and - in them. Momentarily crossed that wire. K > On Aug 7, 2020, at 00:01, Ryan Schmidt wrote: > > > >> On Aug 6, 2020, at 09:10, Ken Cunningham wrote: >> >> So a port that installs the Zoom teleconferencing application would be >> called

Re: port "cask" -- installing prebuilt binaries

Good point. And I just updated postgresql-jdbc, which depends on binary-only openjdk*... :-| > Le 7 août 2020 à 08:59, Ryan Schmidt a écrit : > >  > >> On Aug 5, 2020, at 07:52, Georges Martin wrote: >> >> If MacPorts starts to mix both approaches, I worry we may end up having >> (open

Re: port "cask" -- installing prebuilt binaries

On Aug 6, 2020, at 21:20, Ruben Di Battista wrote: > If they've been built somewhere by the upstream developer, shouldn't we be > able to build them too and hence instead of providing them as binaries we > would fix the ports in order to build on old systems? I guess it's a matter > of how

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 13:34, Arno Hautala wrote: > >> On 6 Aug 2020, at 14:06, Ken Cunningham wrote: >> >> Along with name-suffix, a category was actually one of the first suggestions >> in the original post 50 posts ago, but how does one see which ports you have >> installed that are

Re: port "cask" -- installing prebuilt binaries

On Aug 6, 2020, at 10:32, Arno Hautala wrote: > Have any developers asked for source not to be mirrored? A few; see "port echo license:nomirror"

Re: port "cask" -- installing prebuilt binaries

On Aug 6, 2020, at 09:10, Ken Cunningham wrote: > So a port that installs the Zoom teleconferencing application would be called > "zoom_binary". (We can't use "zoom-binary" because variants us the + and - to > do their thing.) Calling it "zoom-binary" would be fine. Yes, "+" and "-" are

Re: port "cask" -- installing prebuilt binaries

On Aug 5, 2020, at 07:52, Georges Martin wrote: > If MacPorts starts to mix both approaches, I worry we may end up having (open > source) packages depending on closed source, binary packages. We already have that, by necessity. For example, php-excel is an open source php module that

Re: port "cask" -- installing prebuilt binaries

I also believe we should apply this strategy to "binary only" non-open source software. I have a question tho, probably addressed mostly to @Ken and those that manage the ports builds on old systems, in facts, about hybrid ports (as defined by @Herby: open source software that we are unable to

Re: port "cask" -- installing prebuilt binaries

I certainly see your points. Here are my thoughts: On the subject of binary-only ports, you'll have two kinds: - binary ports that are *entirely* binary _only_, and were *never* source-built, no matter the platforms or macOS version (like Zoom for example) - "hybrid" ports that are

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 4:13 PM, Ken Cunningham > wrote: > > We need a new name. No trickery with categories is acceptable here. Picture the ticket: hello, user. Uhm before I can help you, does port list echo categories:binary and installed | grep macvim say “binary” ? No —wait — I meant

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 2:34 PM, Herby G wrote: > > > If we decide to go ahead with this, and if we decide to primarily use a > > category to mark these, we will need a plan for how to manage a name > > collision conflict when there are two ports that install the same software, > > one by

Re: port "cask" -- installing prebuilt binaries

> If we decide to go ahead with this, and if we decide to primarily use a category to mark these, we will need a plan for how to manage a name collision conflict when there are two ports that install the same software, one by building from source (on newer systems) and one by installing a binary

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 12:28 PM, Herby G wrote: > > > so far, name-suffix is winning on all fronts...with no downsides yet. > > I don't plan on pushing the issue, but I have to say that I don't agree. > > Using a name suffix isn't clean, as you may include other non-binary ports > that may

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 1:42 PM, Jason Liu wrote: > > All that said, one more question. As I now understand it, the idea is to > download a binary-only installer (from the publisher’s web site) and launch > it. Someone still has to answer any and all dialogs that such installers > always

Re: port "cask" -- installing prebuilt binaries

> > All that said, one more question. As I now understand it, the idea is to > download a binary-only installer (from the publisher’s web site) and launch > it. Someone still has to answer any and all dialogs that such installers > always present. So, it fact, the administrator has to sit at

Re: port "cask" -- installing prebuilt binaries

> > 2) My impression is that developers of commercial software would, in many > cases, NOT want a third party (like MacPorts) to be distributing their > software. From their perspective, a third party introduces considerably > more risk that users may end up with maliciously altered software.

Re: port "cask" -- installing prebuilt binaries

> All that said, one more question. As I now understand it, the idea is to download a binary-only installer (from the publisher’s web site) and launch it. Someone still has to answer any and all dialogs that such installers always present. So, it fact, the administrator has to sit at the

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 12:28 PM, Herby G wrote: > > > so far, name-suffix is winning on all fronts...with no downsides yet. > > I don't plan on pushing the issue, but I have to say that I don't agree. > I originally suggested both, and got no purchase on either, so had to push one of them

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 12:16 PM, Craig Treleaven wrote: > > > Personally, I don’t see any compelling reason why the MacPorts project should > want to go in this direction. The first paragraph on our homepage says: Actually, I’m perfectly happy with a blanket “NO” on all this, if that is the

Re: port "cask" -- installing prebuilt binaries

> so far, name-suffix is winning on all fronts...with no downsides yet. I don't plan on pushing the issue, but I have to say that I don't agree. Using a name suffix isn't clean, as you may include other non-binary ports that may happen to have the word "binary" in their name. A category allows

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 11:29 AM, Ken Cunningham > wrote: > > All valid points. I thought we had more-or-less got past the “should we” and > moved on to the “how should we”, > > I am not necessarily championing this, but people are submitting these, and > there is demand.here are nearly 4000

Re: port "cask" -- installing prebuilt binaries

> On 6 Aug 2020, at 8:02 pm, Ken Cunningham > wrote: > > category-only identifier is > > less clear and less obvious > harder to remember how to search for > name conflicts with a non-binary version (eg for newer systems that can build > it) > > so far, name-suffix is winning on all

Re: port "cask" -- installing prebuilt binaries

category-only identifier is less clear and less obvious harder to remember how to search for name conflicts with a non-binary version (eg for newer systems that can build it) so far, name-suffix is winning on all fronts...with no downsides yet. K

Re: port "cask" -- installing prebuilt binaries

> On 6 Aug 2020, at 14:06, Ken Cunningham > wrote: > > Along with name-suffix, a category was actually one of the first suggestions > in the original post 50 posts ago, but how does one see which ports you have > installed that are members of that category? > > with a name suffix, easy. >

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 10:50 AM, Herby G wrote: > a "binary"/"binary_only" (or a new MacPorts specific name for these) as a > *category*, just as we have the "aqua" category > in this way, binary-only apps can continue to be represented in respected > categories with "binary" as their

Re: port "cask" -- installing prebuilt binaries

Adding my 2 cents to this as well (why not). I personally think a conservative approach makes sense here. We can keep the entirety of MacPorts structure exactly the way it is today, and add 3 things: - a "binary"/"binary_only" (or a new MacPorts specific name for these) as a *category*,

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 8:23 AM, Arno Hautala wrote: > >> On 6 Aug 2020, at 10:10, Ken Cunningham >> wrote: >> >> How about I float a suggestion? We could append "_binary" to the name. >> Otherwise leave the categories, notes, etc as they are now. > > Could all of the “cask” ports be put

Re: port "cask" -- installing prebuilt binaries

> On 6 Aug 2020, at 11:03, Craig Treleaven wrote: > > So, pretend I don’t know how Homebrew’s cask system works. (I don’t.) > > 1) As a user, what is the advantage of this kind of system versus other > avenues for software (i.e. the Mac App Store or direct download of a dmg from > the

Re: port "cask" -- installing prebuilt binaries

All valid points. I thought we had more-or-less got past the “should we” and moved on to the “how should we”, I am not necessarily championing this, but people are submitting these, and there is demand.here are nearly 4000 cask installer formulae on brew now. If similar binary-only ports are

Re: port "cask" -- installing prebuilt binaries

> On 6 Aug 2020, at 10:10, Ken Cunningham > wrote: > > How about I float a suggestion? We could append "_binary" to the name. > Otherwise leave the categories, notes, etc as they are now. Could all of the “cask” ports be put in a second ports tree? Any source-based ports that wanted to

Re: port "cask" -- installing prebuilt binaries

> On Aug 6, 2020, at 10:10 AM, Ken Cunningham > wrote: > > How about I float a suggestion? We could append "_binary" to the name. > Otherwise leave the categories, notes, etc as they are now. > > So a port that installs the Zoom teleconferencing application would be called > "zoom_binary".

Re: port "cask" -- installing prebuilt binaries

How about I float a suggestion? We could append "_binary" to the name. Otherwise leave the categories, notes, etc as they are now. So a port that installs the Zoom teleconferencing application would be called "zoom_binary". (We can't use "zoom-binary" because variants us the + and - to do

Re: port "cask" -- installing prebuilt binaries

On 8/5/2020 8:12 AM, Lothar Haeger wrote: Am 05.08.2020 um 14:52 schrieb Georges Martin mailto:jrjsm...@gmail.com>>: If MacPorts starts to mix both approaches, I worry we may end up having (open source) packages depending on closed source, binary packages. And have less control on ensuring

Re: port "cask" -- installing prebuilt binaries

> Am 05.08.2020 um 15:11 schrieb Ken Cunningham > : > > the indicator should not be a variant. Variant indicates an option to install > one way or the other, and a given port on a given system will not have such > an option. Well, it's just a suggestion, here's another one: I suggested a port

Re: port "cask" -- installing prebuilt binaries

On 8/4/2020 12:52 PM, Ruben Di Battista wrote: One of the reasons I chose Macports for is the fact it builds its own tree from source and it ships basically open source only software. I think there have been cases where MacPorts' preference/insistence on building from source, even when

Re: port "cask" -- installing prebuilt binaries

> Am 05.08.2020 um 14:52 schrieb Georges Martin : > > If MacPorts starts to mix both approaches, I worry we may end up having (open > source) packages depending on closed source, binary packages. And have less > control on ensuring a consistent, compatible distribution. That's already the

Re: port "cask" -- installing prebuilt binaries

> Sure, let's repeat this a few more times until everyone *really* got that. :-) That's exactly why the indicator should not be a variant. Variant indicates an option to install one way or the other, and a given port on a given system will not have such an option. K

Re: port "cask" -- installing prebuilt binaries

> Am 05.08.2020 um 14:28 schrieb Ken Cunningham > : > > I wasn't imagining a variant for binary-only installs. That's just an idea on how this could be presented to users. Also an easy way to identify ports that are basically binary redistribution (`port list variant:prebuilt`). Also would

Re: port "cask" -- installing prebuilt binaries

> Le 5 août 2020 à 12:52, Lothar Haeger a écrit : > > Even if MacPorts also provided closed source stuff it would still be your > choice to install or not install it. Problem is with dependencies on closed source packages where you have no choice. If I use apt or dnf as part of a Linux

Re: port "cask" -- installing prebuilt binaries

I wasn't imagining a variant for binary-only installs. If a port can be built, we should build it. But for things we can't build, (like Zoom or Microsoft Word) installing a binary is the only option and some ports of this type seem to be what people are submitting recently. This is fine --

Re: port "cask" -- installing prebuilt binaries

> Am 04.08.2020 um 19:52 schrieb Ruben Di Battista : > > So my take here is to not provide pre-built binaries packages if not strictly > unavoidable, like for the osxfuse project (since it was open source before). I think we all agree that building from source is preferred, so nothing should

Re: port "cask" -- installing prebuilt binaries

Ehi, sorry I was not clear enough. Sometimes I’m very bad at expressing what I have in mind, I’m sorry. Hmm, I hadn't heard about that, but I don't run 10.14+ other than for testing. https://github.com/osxfuse/osxfuse/issues/590 Huh? Are you suggesting *disallowing* the use of precompiled

Re: port "cask" -- installing prebuilt binaries

If I understand correctly the reason ffmpeg is a problem is because you can build it in a "non-free" way. In fact, I think the variant is +non_free. I used to use homebrew cask and macports, but then they rolled cask into homebrew and I'll be damned if I install regular old homebrew. I'd love a

Re: port "cask" -- installing prebuilt binaries

On Wed, 29 Jul 2020, Daniel J. Luke wrote: On Jul 29, 2020, at 9:30 PM, Fred Wright wrote: [...] Personally, I'd prefer the MacPorts approach if it were less stingy with the binary archives. Ideally, one should be *able* to build from source, but not be *required* to do so. How is it

Re: port "cask" -- installing prebuilt binaries

I already maintain some ports that install binaries from upstream, like the openjdk* ports, which are very complex to build from source and take many, many hours to build. I also maintain some Go ports that build from source, but that are not available on some older OS versions because the go

Re: port "cask" -- installing prebuilt binaries

So my take here is to not provide pre-built binaries packages if not strictly unavoidable, like for the osxfuse project (since it was open source before). One of the reasons I chose Macports for is the fact it builds its own tree from source and it ships basically open source only software.

Re: port "cask" -- installing prebuilt binaries

There's is one compelling need for having "binary only" install, and that is for the port "osxfuse", that is currently broken for 10.14+. There was a discussion about it on the Github project about the choice of making it close closed source... Nonetheless it would be useful to have it in order

Re: port "cask" -- installing prebuilt binaries

> Am 30.07.2020 um 08:03 schrieb Ken Cunningham > : > I only raise the idea as people are already doing this, and submitting such > ports, and before we have too many, there is an opportunity to say how it > should best be done (custom category, naming convention, etc). Reminds me of an

Re: port "cask" -- installing prebuilt binaries

> >> From the user's perspective, how does that differ from a port that's > > available as a binary archive? I presume the idea is that it directly uses > > a precompiled binary from the upstream source, but from the user's > > perspective, does it really matter whether it was a binary from

Re: port "cask" -- installing prebuilt binaries

On Jul 29, 2020, at 9:30 PM, Fred Wright wrote: > On Wed, 29 Jul 2020, Ken Cunningham wrote: >> there seems to be demand for replicating the “binary only” installers of >> homebrew cask. >> >> we have a few ports that do that now, and I see more and more coming in. > >> From the user's

Re: port "cask" -- installing prebuilt binaries

On Wed, 29 Jul 2020, Ken Cunningham wrote: there seems to be demand for replicating the “binary only” installers of homebrew cask. we have a few ports that do that now, and I see more and more coming in. From the user's perspective, how does that differ from a port that's available as a