port "cask" -- installing prebuilt binaries

[Herby G]

> 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 machine
and click “OK” ad nauseam.  Previously, I thought we were going to create a
new binary image that would avoid such tedium.  Do I have this right?  Or
is there some scripting trickery wrapped around the installer?

That is not always the case.  There is plenty of binary-only software
that's literally a binary or an app bundle in a .dmg or zip file equivalent.

A good example of this is the port for the 1Password CLI (
https://github.com/macports/macports-ports/blob/master/security/1password-cli/Portfile),
or a .app bundle meant to be extracted into your Applications directory.

Those are excellent candidates for what Ken is talking about.  Even for
some ports that are way too onerous to build, some of the utilities for
handling binary-only ports can be used for making it easier to provide the
pre-built distributable(s) of such a piece of software, just as Nils was
saying at the start of this thread.

On Thu, Aug 6, 2020 at 3:16 PM Craig Treleaven <ctreleaven at macports.org>
wrote:

> On Aug 6, 2020, at 11:29 AM, Ken Cunningham <
> ken.cunningham.webuse at gmail.com> 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 cask installer formulae on brew
> now. If similar binary-only ports are going to be accepted, I was hoping
> for a mechanism to identify and control them somewhat, for the reasons you
> mention and more.
>
>
> 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 developer web site)?
>
>
> convenience, really. You can install something with a short command
> instead of wading through finding the right installer on a website. Updates
> are handled transparently. You can install 10 or 20 software packages onto
> a set of systems with one command. You can make a list of the 75 software
> packages you like to have and install them all with one command. You can
> tell your grandmother how to install zoom with four words to paste into a
> terminal instead of a complicated set of download and install instructions.
>
> Doesn’t most such software include an auto-updater?
>
>
> Sometimes.
>
> If so, won’t that conflict with MacPorts update handling?
>
>
> Yes.
>
> A potential disadvantage would be the time lag from a new version being
> released until a new ‘cask’ is available, right?
>
>
> Yes
>
>
> If I understand correctly, this is a facility that would only benefit
> system administrators that have a fleet of Macs that are more-or-less
> configured the same.  It would help them to automate the process of
> installing and updating software whether the software is open-source or
> only available as a binary.  (But not software that is only on the Mac App
> Store.)  Is that right?
>
> That is a worthy audience but why is this something that MacPorts should
> address?  I believe there are already 'multiple device management systems'
> out there that support macOS.  And if Homebrew already provides 4,000
> packages, why do we want to do the same?  Is it not possible to combine
> Homebrew’s casks with open source software installed by MacPorts?
>
> MacPorts is not in competition with Homebrew.  Really.  The projects have
> different objectives and goals and that is perfectly fine.  Both
> communities have sufficient support to continue for the foreseeable
> future.  We don’t have to “defeat them” to “win” or vice versa.  We seem to
> be aiming to replicate their cask system.  Should we not be aiming to
> provide a system that is demonstrably *better* than what is currently
> available?
>
> 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 machine
> and click “OK” ad nauseam.  Previously, I thought we were going to create a
> new binary image that would avoid such tedium.  Do I have this right?  Or
> is there some scripting trickery wrapped around the installer?
>
> 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:
>
> "The MacPorts Project is an open-source community initiative to design an
> easy-to-use system for compiling, installing, and upgrading either
> command-line, X11 or Aqua based open-source software on the Mac operating
> system <http://www.apple.com/macos/>. To that end we provide the
> command-line driven MacPorts software package under a 3-Clause BSD License
> <http://opensource.org/licenses/BSD-3-Clause>, and through it easy access
> to thousands of ports that greatly simplify
> <https://guide.macports.org/#introduction> the task of compiling and
> installing <https://guide.macports.org/#using> open-source software on
> your Mac.”
>
> This effectively our charter and binary-only doesn’t fit.  The watchword
> at Apple is “a thousand no’s for every yes”.  IOW, focus on doing the right
> things really well and don’t get distracted trying to do all the other
> stuff just because it is possible.  Just because we _could_ provide binary
> packages doesn’t mean that we should.
>
> IMHO, YMMV, etc.
>
> Craig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200806/0f8fc65a/attachment-0001.htm>