Adding my 2 cents to this as well (why not). I personally think a conservative approach makes sense here.
We can keep the entirety of MacPorts structure exactly the way it is today, and add 3 things: - 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 - 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. On Thu, Aug 6, 2020 at 12:02 PM Ken Cunningham < ken.cunningham.web...@gmail.com> wrote: > > > > On Aug 6, 2020, at 8:23 AM, Arno Hautala <a...@alum.wpi.edu> wrote: > > > >> On 6 Aug 2020, at 10:10, Ken Cunningham < > ken.cunningham.web...@gmail.com> wrote: > >> > >> How about I float a suggestion? We could append "_binary" to the name. > Otherwise leave the categories, notes, etc as they are now. > > > > Could all of the “cask” ports be put in a second ports tree? > > 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. > > > > 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. > > Now extremely difficult to implement. > > > > > Personally, I dislike the idea of a port name suffix, but an attribute > that could be searched for is a good idea. > > > 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. > > 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. > > port -v installed | grep binary > > 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. > > K