> > 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 <[email protected]> wrote: > On Aug 6, 2020, at 11:29 AM, Ken Cunningham < > [email protected]> 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 > >
