> >> 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 upstream or
> > a binary from the buildbots?
> >
> > Or is this for ports where upstream doesn't provide source at all?
> >
> > 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 stingy? We have binary archives for everything that the buildbots
> can build that the licenses allow us to distribute, right?
>
> port, by default, will use the binary archives unless you tell it to build
> from source instead.
> --
These “cask” binaries are generally the official downloadable software packages
you would get from the project or website of the company or group providing the
software, built the way they build it, with their libraries integrated into the
binaries, their update mechanisms, their range of allowed deployment targets.
There are upsides and downsides to this. Clearly if we can build it, we should.
But there are things we can’t build, for example “Zoom” is a good one. But
there are hundreds of others. Until now, MacPorts didn’t try to provide these
things, but there seems to be a demand for command-line binary installers.
Having used homebrew cask to install about 100 of these in one fell swoop, it
was convenient, until the warts started showing up and I had to uninstall about
1/2 of them for various reasons.
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).
K
