<div dir="ltr">If I understand correctly the reason ffmpeg is a problem is because you can build it in a "non-free" way. In fact, I think the variant is +non_free.<div><br>I used to use homebrew cask and macports, but then they rolled cask into homebrew and I'll be damned if I install regular old homebrew. I'd love a way to do the same with ports, but I honestly have no idea exactly how it would work and how to differentiate the FOSS stuff from the binary only stuff.</div><div><br></div><div>—Mark</div><div><br></div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 4, 2020 at 4:35 PM Fred Wright <<a href="mailto:fw@fwright.net">fw@fwright.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On Wed, 29 Jul 2020, Daniel J. Luke wrote:<br>
> On Jul 29, 2020, at 9:30 PM, Fred Wright <<a href="mailto:fw@fwright.net" target="_blank">fw@fwright.net</a>> wrote:<br>
[...]<br>
>> Personally, I'd prefer the MacPorts approach if it were less stingy <br>
>> with the binary archives.  Ideally, one should be *able* to build from <br>
>> source, but not be *required* to do so.<br>
><br>
> How is it stingy? We have binary archives for everything that the <br>
> buildbots can build that the licenses allow us to distribute, right?<br>
<br>
Aside from the usual issues with non-default variants and certain old OS <br>
versions, the main problem seems to be what appears to be an overly strict <br>
interpretation of "distributable".<br>
<br>
As a random example, consider ffmpeg.  The license for ffmpeg shows as <br>
GPL-2+.  Although GPL prohibits binary-only distributions at the "meta <br>
level", it does *not* demand that sources be bundled with the binaries. <br>
It simply says that if they're not, there has to be clear information <br>
available to the user on how to obtain the sources.  It doesn't even <br>
demand a working build procedure, just the sources.  It might get a bit <br>
fuzzy in cases where the sources are patched, in which case it's not 100% <br>
clear that providing the original source plus the patches is adequate, or <br>
whether it's necessary to provide the actual patched sources (though the <br>
two are certainly morally equivalent), but in any case, MacPorts clearly <br>
does both.  Anyone can get the upstream source archive(s) via "port <br>
fetch", get the sources in tree form via "port extract", and get the <br>
patched sources via "port patch".  I don't see how this fails to meet the <br>
GPL requirements for any MacPorts user.<br>
<br>
Now if one were to be really paranoid, one might consider that providing <br>
binaries on servers that are accessible by means other than MacPorts could <br>
constitute a GPL violation, due to not having the "clear path to sources" <br>
that MacPorts provides.  But if that's a concern, it could be easily <br>
addressed by including a README.sources file in every directory on the <br>
archive servers, either pointing to the corresponding source on a distfile <br>
mirror (or directly upstream if necessary), or perhaps just pointing to <br>
the MacPorts homepage.<br>
<br>
And to pick a random sub-example, Debian offers ffmpeg as a binary <br>
package.<br>
<br>
> port, by default, will use the binary archives unless you tell it to <br>
> build from source instead.<br>
<br>
BTW, on an only mildly related note, I've seen a number of cases lately <br>
where it successfully fetches a binary archive and than fails to fetch the <br>
corresponding checksum file.  It seems that it gets only one chance to do <br>
this, and only from the same mirror where it fetched the archive.  It's <br>
become common for me to need a "cleanup pass" after doing "upgrade <br>
outdated" across my VMs, where I manually retry the failed upgrades.<br>
<br>
On Tue, 4 Aug 2020, Ruben Di Battista wrote:<br>
<br>
> There's is one compelling need for having "binary only" install, and that<br>
> is for the port "osxfuse", that is currently broken for 10.14+.<br>
><br>
> There was a discussion about it on the Github project about the choice of<br>
> making it close closed source... Nonetheless it would be useful to have it<br>
> in order to provide things like fuse file systems and so on.<br>
<br>
Hmm, I hadn't heard about that, but I don't run 10.14+ other than for <br>
testing.<br>
<br>
I was involved in fixing some osxfuse bugs right around the time that <br>
10.10 came out, making kext signature checking mandatory.  On 10.9, it <br>
warns you about an unsigned kext, but you can tell it to proceed.  The fix <br>
at the time (for the relevant OS versions) was to have MacPorts fetch the <br>
binary distribution and extract the signed prebuilt kext from it, while <br>
building the rest from sources.  This is done starting with 10.9, to avoid <br>
the dialog box, even though it's not strictly necessary until 10.10+.<br>
<br>
It sounds like some more tightening of the security noose has caused <br>
additional problems for osxfuse.<br>
<br>
On Tue, 4 Aug 2020, Ruben Di Battista wrote:<br>
<br>
> So my take here is to not provide pre-built binaries packages if not<br>
> strictly unavoidable, like for the osxfuse project (since it was open<br>
> source before).<br>
<br>
Huh?  Are you suggesting *disallowing* the use of precompiled binaries? <br>
That would be crazy.<br>
<br>
The amount of both human and computer time that's wasted rebuilding the <br>
same binaries from the same sources with the same options is humongous.<br>
<br>
Another thing that's often overlooked is that installing precompiled <br>
binaries, especially when signed, is more secure than building from <br>
sources.  This is because the attack surface of the tools required to <br>
install binaries is far smaller than the attack surface of the toolchains <br>
needed to build them.  If you think this is purely hypothetical, consider <br>
the early Unix hack that implemented a backdoor that didn't appear in any <br>
source code.<br>
<br>
> One of the reasons I chose Macports for is the fact it builds its own tree<br>
> from source and it ships basically open source only software.<br>
<br>
Anyone is free to configure it to do that.  I suppose there could be a <br>
strict source-only option that flatly refuses to install any port that <br>
can't be completely built from source, but I doubt that many people would <br>
use it.<br>
<br>
Fred Wright<br>
</blockquote></div>