port "cask" -- installing prebuilt binaries

Tue Aug 4 23:30:55 UTC 2020

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 <fw at fwright.net> wrote:

>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200804/6ddf5322/attachment-0001.htm>