<html><head><style>body{font-family:Merriweather,Arial;font-size:13px}</style></head><body><div style="font-family:Merriweather,Arial;font-size:13px;color:rgba(51,51,51,1.0)">Ehi, sorry I was not clear enough. Sometimes I’m very bad at expressing what I have in mind, I’m sorry.</div><div style="font-family:Merriweather,Arial;font-size:13px;color:rgba(51,51,51,1.0)"><br></div><div style="font-family:Merriweather,Arial;font-size:13px;color:rgba(51,51,51,1.0)"><div><blockquote type="cite" class="clean_bq" style="font-family:Merriweather,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">Hmm, I hadn't heard about that, but I don't run 10.14+ other than for <br>testing. </blockquote></div><p><a href="https://github.com/osxfuse/osxfuse/issues/590">https://github.com/osxfuse/osxfuse/issues/590</a></p><div><blockquote type="cite" class="clean_bq" style="font-family:Merriweather,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">Huh? Are you suggesting *disallowing* the use of precompiled binaries? <br>That would be crazy. </blockquote></div><p>No, no. What I meant was to limit “cask behavior”, that for what I understand is “binary-only” distribution, to only the ports that really really are needed (like, for my use case, osxfuse). </p><p>The current approach seems reasonable and philosophically closer to the FOSS movement (i.e. shipping default variants distributable ports as binaries…). Maybe expanding the matrix of builds to more variants would be also cool, but I imagine that this would require an insane amount of space on the servers...</p></div> <br> <div class="gmail_signature"><pre><code>          _   

-.     .´  |∞∞∞∞

  ',  ;    |∞∞∞∞∞∞

    ˜˜     |∞∞∞∞∞∞∞∞∞ RdB

    ,.,    |∞∞∞∞∞∞

  .'   '.  |∞∞∞∞

-'       `’

<a href="https://rdb.is">https://rdb.is</a>

</code></pre></div> <br><p class="airmail_on">On 4 August 2020 at 22:35:47, Fred Wright (<a href="mailto:fw@fwright.net">fw@fwright.net</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>

<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">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  

>> source, but not be *required* to do so.

<br>>

<br>> How is it stingy? We have binary archives for everything that the  

> 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  

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  

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  

the MacPorts homepage.

<br>

<br>And to pick a random sub-example, Debian offers ffmpeg as a binary  

package.

<br>

<br>> port, by default, will use the binary archives unless you tell it to  

> 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  

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

> 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

> 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  

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  

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  

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?  

That would be crazy.

<br>

<br>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.

<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  

source code.

<br>

<br>> 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.

<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  

use it.

<br>

<br>Fred Wright

<br></div></div></span></blockquote></body></html>