<div dir="ltr">Adding my 2 cents to this as well (why not).<div><br></div><div>I personally think a conservative approach makes sense here.</div><div><br></div><div>We can keep the entirety of MacPorts structure exactly the way it is today, and add 3 things:</div><div><ul><li>a "binary"/"binary_only" (or a new MacPorts specific name for these) as a *category*, just as we have the "aqua" category</li><ul><li>in this way, binary-only apps can continue to be represented in respected categories with "binary" as their secondary or third category</li></ul><li>a portgroup with the name selected above, which as mentioned earlier, could perhaps have:</li><ul><li>a blank build section and use_configure disabled since binary ports are extract-only</li><li>automatic support to destroot and install <Name>.app bundles into the $prefix/Applications dir</li><li>by default turning on any options that might exist to disable caching/mirroring of the distfile, and disable attempting to check MacPorts official mirrors for the same.</li><ul><li>The port maintainer should be able to disable this to return to standard MacPorts caching + mirroring behavior at his/her discretion</li></ul></ul><li>perhaps lint additions to warn the user if they are indeed doing a build or configure on a port that has been marked as being in the "binary" category<br></li></ul><div>In this way, we don't need to have major changes to the MacPorts structure, but now can track binary-only ports.</div></div><div>If any special sub-commands need to be added for binary-only ports, these commands need only target ports in this "binary" category.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 6, 2020 at 12:02 PM Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com">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 8:23 AM, Arno Hautala <<a href="mailto:arno@alum.wpi.edu" target="_blank">arno@alum.wpi.edu</a>> wrote:<br>
> <br>
>> On 6 Aug 2020, at 10:10, Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com" target="_blank">ken.cunningham.webuse@gmail.com</a>> wrote:<br>
>> <br>
>> How about I float a suggestion? We could append "_binary" to the name. Otherwise leave the categories, notes, etc as they are now. <br>
> <br>
> Could all of the “cask” ports be put in a second ports tree?<br>
<br>
Very very difficult to implement. Not impossible. You’d have to have some new logic in the “port” command, and a new keyword like “cask” or “binary” or some better keyword, that searches a new ports tree. Realistically — not likely to ever happen, and if it does, not likely to happen any time soon.<br>
<br>
<br>
> Any source-based ports that wanted to depend on those would also need to go in that tree or at least couldn’t be in the source-only tree. The tree wouldn’t ship by default, or at least would have to be enabled (“uncommented”) in a config file.<br>
<br>
Now extremely difficult to implement.<br>
<br>
> <br>
> Personally, I dislike the idea of a port name suffix, but an attribute that could be searched for is a good idea.<br>
<br>
<br>
When you type “port search XYZ”, the idea is to somehow immediately see that XYZ is a prebuilt binary you might or might not want install. If it’s not in the name, I don’t see how to do it.<br>
<br>
When you want to know what prebuilt binaries you have installed so you can purge them all, you need to have a simple command you can type to identify them all.<br>
<br>
port -v installed | grep binary<br>
<br>
is pretty simple. Hopefully someone on this list knows a better way, or perhaps there is a way to make a command internal to “port” do it bettter.<br>
<br>
K</blockquote></div>