<div dir="auto"><div>I also believe we should apply this strategy to "binary only" non-open source software.<div dir="auto"><br></div><div dir="auto">I have a question tho, probably addressed mostly to @Ken and those that manage the ports builds on old systems, in facts, about hybrid ports (as defined by @Herby: open source software that we are unable to build on some systems and then we ship it as binary only). </div><div dir="auto"><br></div><div dir="auto">If they've been built somewhere by the upstream developer, shouldn't we be able to build them too and hence instead of providing them as binaries we would  fix the ports in order to build on old systems? I guess it's a matter of how hard is to fix the build environment on old systems... </div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 7 Aug 2020, 03:56 Herby G, <<a href="mailto:herby.gillot@gmail.com">herby.gillot@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I certainly see your points. Here are my thoughts:<div><br></div><div>On the subject of binary-only ports, you'll have two kinds:</div><div><ul><li>binary ports that are *entirely* binary _only_, and were *never* source-built, no matter the platforms or macOS version (like Zoom for example)</li><li>"hybrid" ports that are source-compiled under certain conditions, and fetching a binary in other cases</li></ul><div>The first thing to consider is what's the ratio of pure-binary to "hybrid" binary ports? I feel like "hybrid" ones would be in the minority.  Homebrew's "casks" are mostly pure binary-only.</div><div><br></div><div>One thing that can be done to simplify things is have the condition that only "purely" binary ports can be in the "binary" category (for simplicity's sake).</div><div><br></div><div>Hybrid ports are going to be a hassle no matter what, and that would be true for any port that has conditional logic that changes the port's behavior depending on macOS version and other factors (besides architecture).</div><div><br></div><div>When someone is filing a ticket, we'd want to know their macOS version + environmental details anyway, and that tells you what you need to know as a maintainer to troubleshoot a hybrid port that you are maintaining.</div><div><br></div><div>Now the headaches you illustrate have a lot to do with how a hybrid port would be implemented.</div><div><br></div><div>Two ways that immediately come to mind are:</div><div><ul><li>sub-ports: your main port installs a source-built or binary-only sub-port depending on macOS version</li><li>same port but using conditional logic internally</li></ul><div>In the first case, each sub-port would have to have a different name, so that's that.</div></div><div>In the case of the second, yes, that can lead to the scenario you illustrated, but as I mentioned above, once we know the user's environment, we can know what's installed.</div><div><br></div><div>I am not against having different names for a binary-only vs source-built version of a port.  But that only matters in the case where the same piece of software is source-based in one place and binary-only elsewhere.</div><div><br></div><div>I think using a category to mark binary-only ports is far more optimal than packing that meaning into the port's name, especially when ports can choose almost any name they want.</div><div><br></div><div>Additionally, as I've mentioned previously, it's much easier for tooling like the MacPorts website, the port command and more to tell based off a category than a list of blessed regexes for determining whether a port _might be_ binary only (as it's possible some other port may have "binary" in its name even though it may not be).</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 6, 2020 at 7:13 PM Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com" target="_blank" rel="noreferrer">ken.cunningham.webuse@gmail.com</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>
<br>
> On Aug 6, 2020, at 2:34 PM, Herby G <<a href="mailto:herby.gillot@gmail.com" target="_blank" rel="noreferrer">herby.gillot@gmail.com</a>> wrote:<br>
> <br>
> > If we decide to go ahead with this, and if we decide to primarily use a category to mark these, we will need a plan for how to manage a name collision conflict when there are two ports that install the same software, one by building from source (on newer systems) and one by installing a binary (on older systems).<br>
<br>
> This does not introduce any new mechanism or concept that does not already currently exist in MacPorts.<br>
> <br>
<br>
yes it does. An example: let’s take the port MacVIM, which is ripe for this treatment.<br>
<br>
We can build and install the current macvim on some newer systems - let’s say 10.12 to current.<br>
<br>
port -v install macvim gets you that.<br>
<br>
We will all know what that port represents, without trouble, if there is a ticket.<br>
<br>
Now say on 10.7 to 10.11, we want to install a binary version of macvim. macvim won't build on those systems, but there is a binary that works.<br>
<br>
We need a clear, identifiable port name to install the macvim binary. It should not be called macvim, that is just a *crazy* recipe for trouble. You’d never be able to keep up with what was what. We need the port to clearly be recognizable as the macvim binary.<br>
<br>
We need a new name. No trickery with categories is acceptable here.<br>
<br>
The “macvim” port might (or might not) point a user to the macvim_binary port if needed, but it can’t be the same port with the same name, and it most definitely should not install the binary instead. If we go down that road, we’ll never know what is going on, and this whole idea would best be left not done.<br>
<br>
Like<br>
<br>
<br>
<br>
</blockquote></div>
</blockquote></div></div></div>