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.
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. —Mark On Tue, Aug 4, 2020 at 4:35 PM Fred Wright <f...@fwright.net> wrote: > > On Wed, 29 Jul 2020, Daniel J. Luke wrote: > > On Jul 29, 2020, at 9:30 PM, Fred Wright <f...@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 >
