port "cask" -- installing prebuilt binaries

[Herby G]

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.webuse at gmail.com> wrote:

>
>
> > On Aug 6, 2020, at 8:23 AM, Arno Hautala <arno at alum.wpi.edu> wrote:
> >
> >> On 6 Aug 2020, at 10:10, Ken Cunningham <
> ken.cunningham.webuse at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200806/9a9e88c8/attachment.htm>