<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 6, 2020, at 10:50 AM, Herby G <<a href="mailto:herby.gillot@gmail.com" class="">herby.gillot@gmail.com</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class=""><ul class=""></ul></div></div></div></blockquote><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><ul class=""><li class="">a "binary"/"binary_only" (or a new MacPorts specific name for these) as a *category*, just as we have the "aqua" category</li><ul class=""><li class="">in this way, binary-only apps can continue to be represented in respected categories with "binary" as their secondary or third category</li></ul></ul></div></div></div></blockquote><div><br class=""></div><div>Along with name-suffix, a category was actually one of the first suggestions in the original post 50 posts ago, but how does one see which ports you have installed that are members of that category?</div><div><br class=""></div><div>with a name suffix, easy.</div><div><br class=""></div><div>port -v installed | grep binary</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><ul class=""><li class="">a portgroup with the name selected above, which as mentioned earlier, could perhaps have:</li><ul class=""><li class="">a blank build section and use_configure disabled since binary ports are extract-only</li><li class="">automatic support to destroot and install <Name>.app bundles into the $prefix/Applications dir</li><li class="">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 class=""><li class="">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 class="">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 class=""></li></ul><div class="">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 class="">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 class=""></div></blockquote><br class=""></div><div><br class=""></div><div>I think all this other stuff would be best implemented as simple templates for binary-only ports, one for dmg, one for pkg, one for simple xz/tar.gz./etc usual compressed files.</div><div><br class=""></div><div>I have come to basically hate/strongly dislike PortGroups, as they make a total mess out of understanding what the H*LL is going on, esp for new contributors.</div><div><br class=""></div><div>K</div><br class=""></body></html>