"cask" ports just keep on rolling in...

[Ryan Schmidt]

On Feb 5, 2021, at 13:00, Ken Cunningham wrote:

> With no plan, we’ll just keep getting more and more of these.

I'm not aware of a huge influx of these, but I'm also not really paying attention to the PR queue. And I'm not intending to get drawn into this discussion of binary ports again.


> <https://github.com/macports/macports-ports/pull/9936>
> 
> This kind of port just repackages the DMG into many tgz archives.
> 
> It’s wasteful. People want them.
> 
> What we should have instead of this is some kinda tech that
> 
> 1. downloads the DMG
> 2. installs the app
> 3. records some way of uninstalling everything

MacPorts already does all these things... The submitted Portfile works fine, presumably. There's no need to reinvent the existing MacPorts functionality that does all these things.


> What we have instead is a repackaging of the DMG into many, identical, system-specific archive bundles.
> 
> Yuk.

If your objection is that we waste server space storing several copies of the same thing, then we could invent a new way for a portfile to indicate that it does not want binary archives stored on the server. It could be a new separate keyword or a new pseudo license type, like we already have for "nomirror" which tells the buildbot not to mirror the distfiles.

A port like the one we're talking about in the above PR could set e.g. "license GPL-2 nopackage", and buildbot could be modified to understand that this means that it should not upload the packages.

MacPorts base would still try to download the nonexistent package. MacPorts base currently does not use license values except to display to the user and has no idea if a port is distributable. Distributability is handled by a separate script. It should be integrated into base so that base can know if something could have been distributed, and if it could not have, then it shouldn't even try to download it. https://trac.macports.org/ticket/60315

We might also want to modify the MacPorts base command line "-b" binary only mode to allow installing these "nopackage" ports rather than error out as it would currently do.

If the few steps like disabling the configure and build phases and adding the hypothetical "nopackage" to the license line are too much work for a portfile submitter to do, a portgroup could be created that does those things. But you have often complained about "magic" portgroups doing things you didn't know about or didn't expect, so there is something to be said for ports doing what they need to do explicitly, when it's not so many steps, and when it's not always the same steps needing to be done. For example, surely each port will still need to specify what the archs of the binary files are, what license they're under, what type of distfile it is and where it is, and which files inside needs to be copied where.