port "cask" -- installing prebuilt binaries

[Fred Wright]

On Wed, 29 Jul 2020, Daniel J. Luke wrote:
> On Jul 29, 2020, at 9:30 PM, Fred Wright <fw at fwright.net> wrote:
[...]
>> Personally, I'd prefer the MacPorts approach if it were less stingy 
>> with the binary archives.  Ideally, one should be *able* to build from 
>> source, but not be *required* to do so.
>
> How is it stingy? We have binary archives for everything that the 
> buildbots can build that the licenses allow us to distribute, right?

Aside from the usual issues with non-default variants and certain old OS 
versions, the main problem seems to be what appears to be an overly strict 
interpretation of "distributable".

As a random example, consider ffmpeg.  The license for ffmpeg shows as 
GPL-2+.  Although GPL prohibits binary-only distributions at the "meta 
level", it does *not* demand that sources be bundled with the binaries. 
It simply says that if they're not, there has to be clear information 
available to the user on how to obtain the sources.  It doesn't even 
demand a working build procedure, just the sources.  It might get a bit 
fuzzy in cases where the sources are patched, in which case it's not 100% 
clear that providing the original source plus the patches is adequate, or 
whether it's necessary to provide the actual patched sources (though the 
two are certainly morally equivalent), but in any case, MacPorts clearly 
does both.  Anyone can get the upstream source archive(s) via "port 
fetch", get the sources in tree form via "port extract", and get the 
patched sources via "port patch".  I don't see how this fails to meet the 
GPL requirements for any MacPorts user.

Now if one were to be really paranoid, one might consider that providing 
binaries on servers that are accessible by means other than MacPorts could 
constitute a GPL violation, due to not having the "clear path to sources" 
that MacPorts provides.  But if that's a concern, it could be easily 
addressed by including a README.sources file in every directory on the 
archive servers, either pointing to the corresponding source on a distfile 
mirror (or directly upstream if necessary), or perhaps just pointing to 
the MacPorts homepage.

And to pick a random sub-example, Debian offers ffmpeg as a binary 
package.

> port, by default, will use the binary archives unless you tell it to 
> build from source instead.

BTW, on an only mildly related note, I've seen a number of cases lately 
where it successfully fetches a binary archive and than fails to fetch the 
corresponding checksum file.  It seems that it gets only one chance to do 
this, and only from the same mirror where it fetched the archive.  It's 
become common for me to need a "cleanup pass" after doing "upgrade 
outdated" across my VMs, where I manually retry the failed upgrades.

On Tue, 4 Aug 2020, Ruben Di Battista wrote:

> There's is one compelling need for having "binary only" install, and that
> is for the port "osxfuse", that is currently broken for 10.14+.
>
> There was a discussion about it on the Github project about the choice of
> making it close closed source... Nonetheless it would be useful to have it
> in order to provide things like fuse file systems and so on.

Hmm, I hadn't heard about that, but I don't run 10.14+ other than for 
testing.

I was involved in fixing some osxfuse bugs right around the time that 
10.10 came out, making kext signature checking mandatory.  On 10.9, it 
warns you about an unsigned kext, but you can tell it to proceed.  The fix 
at the time (for the relevant OS versions) was to have MacPorts fetch the 
binary distribution and extract the signed prebuilt kext from it, while 
building the rest from sources.  This is done starting with 10.9, to avoid 
the dialog box, even though it's not strictly necessary until 10.10+.

It sounds like some more tightening of the security noose has caused 
additional problems for osxfuse.

On Tue, 4 Aug 2020, Ruben Di Battista wrote:

> So my take here is to not provide pre-built binaries packages if not
> strictly unavoidable, like for the osxfuse project (since it was open
> source before).

Huh?  Are you suggesting *disallowing* the use of precompiled binaries? 
That would be crazy.

The amount of both human and computer time that's wasted rebuilding the 
same binaries from the same sources with the same options is humongous.

Another thing that's often overlooked is that installing precompiled 
binaries, especially when signed, is more secure than building from 
sources.  This is because the attack surface of the tools required to 
install binaries is far smaller than the attack surface of the toolchains 
needed to build them.  If you think this is purely hypothetical, consider 
the early Unix hack that implemented a backdoor that didn't appear in any 
source code.

> One of the reasons I chose Macports for is the fact it builds its own tree
> from source and it ships basically open source only software.

Anyone is free to configure it to do that.  I suppose there could be a 
strict source-only option that flatly refuses to install any port that 
can't be completely built from source, but I doubt that many people would 
use it.

Fred Wright