port "cask" -- installing prebuilt binaries

Thu Aug 6 20:42:55 UTC 2020

>
> 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?

The situation of dialog boxes and clicking "OK" ad nauseam is, in most
cases, completely unnecessary. Installing binary-only installers (.dmg or
.pkg) can be accomplished exclusively using the command line:

If the installer is a .dmg:

# hdiutil mount software-title.dmg

Once the DMG is mounted, if it's just the app, then

# cp -R "/Volumes/Mounted DMG/Software Title.app" /Applications

on the other hand, if the contents are a .pkg, then

# /usr/bin/installer -package "/Volumes/Mounted DMG/Software Installer.pkg"
-target "/Volumes/Macintosh HD"

Finally, unmount the DMG:

# hdiutil unmount "/Volumes/Mounted DMG"

For the vast majority of cases, no manual user intervention is necessary.
In fact, software deployment tools such as Jamf/Casper, Munki, and even
Apple MDM, use this method to perform non-interactive remote installations
of Mac software.

-- 
Jason Liu

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/f76df49d/attachment-0001.htm>