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.
