> On Aug 6, 2020, at 10:10 AM, Ken Cunningham <[email protected]> > 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". (We can't use "zoom-binary" because variants us the + and - to > do their thing.) You could find all your installed binaries with a simple > grep... > > Open to a more descriptive, shorter suffix if anyone is thinking of one. > > Once we find metadata we agree on, then two more points to work out. > 1. Should we mirror the binary installers (no, I'd say)? > 2. We should require a mechanism to remove all traces of the software when > uninstalling it, I think. >
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)? Doesn’t most such software include an auto-updater? If so, won’t that conflict with MacPorts update handling? A potential disadvantage would be the time lag from a new version being released until a new ‘cask’ is available, right? 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. Can we not expect to get takedown notices from certain publishers? 3) Is the MacPorts mirror network willing to contribute bandwidth for distributing non-open source software? Will we sour our relations with some of the mirrors if we use/abuse their bandwidth this way? Why do we want to use our bandwidth that way? Craig
