> On Aug 6, 2020, at 10:50 AM, Herby G <[email protected]> wrote:
> a "binary"/"binary_only" (or a new MacPorts specific name for these) as a > *category*, just as we have the "aqua" category > in this way, binary-only apps can continue to be represented in respected > categories with "binary" as their secondary or third category 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? with a name suffix, easy. port -v installed | grep binary > a portgroup with the name selected above, which as mentioned earlier, could > perhaps have: > a blank build section and use_configure disabled since binary ports are > extract-only > automatic support to destroot and install <Name>.app bundles into the > $prefix/Applications dir > 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. > The port maintainer should be able to disable this to return to standard > MacPorts caching + mirroring behavior at his/her discretion > 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 > In this way, we don't need to have major changes to the MacPorts structure, > but now can track binary-only ports. > If any special sub-commands need to be added for binary-only ports, these > commands need only target ports in this "binary" category. > 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. 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. K
