port "cask" -- installing prebuilt binaries

[Herby G]

I certainly see your points. Here are my thoughts:

On the subject of binary-only ports, you'll have two kinds:

   - binary ports that are *entirely* binary _only_, and were *never*
   source-built, no matter the platforms or macOS version (like Zoom for
   example)
   - "hybrid" ports that are source-compiled under certain conditions, and
   fetching a binary in other cases

The first thing to consider is what's the ratio of pure-binary to "hybrid"
binary ports? I feel like "hybrid" ones would be in the minority.
Homebrew's "casks" are mostly pure binary-only.

One thing that can be done to simplify things is have the condition that
only "purely" binary ports can be in the "binary" category (for
simplicity's sake).

Hybrid ports are going to be a hassle no matter what, and that would be
true for any port that has conditional logic that changes the port's
behavior depending on macOS version and other factors (besides
architecture).

When someone is filing a ticket, we'd want to know their macOS version +
environmental details anyway, and that tells you what you need to know as a
maintainer to troubleshoot a hybrid port that you are maintaining.

Now the headaches you illustrate have a lot to do with how a hybrid port
would be implemented.

Two ways that immediately come to mind are:

   - sub-ports: your main port installs a source-built or binary-only
   sub-port depending on macOS version
   - same port but using conditional logic internally

In the first case, each sub-port would have to have a different name, so
that's that.
In the case of the second, yes, that can lead to the scenario you
illustrated, but as I mentioned above, once we know the user's environment,
we can know what's installed.

I am not against having different names for a binary-only vs source-built
version of a port.  But that only matters in the case where the same piece
of software is source-based in one place and binary-only elsewhere.

I think using a category to mark binary-only ports is far more optimal than
packing that meaning into the port's name, especially when ports can choose
almost any name they want.

Additionally, as I've mentioned previously, it's much easier for tooling
like the MacPorts website, the port command and more to tell based off a
category than a list of blessed regexes for determining whether a port
_might be_ binary only (as it's possible some other port may have "binary"
in its name even though it may not be).


On Thu, Aug 6, 2020 at 7:13 PM Ken Cunningham <
ken.cunningham.webuse at gmail.com> wrote:

>
>
> > On Aug 6, 2020, at 2:34 PM, Herby G <herby.gillot at gmail.com> wrote:
> >
> > > If we decide to go ahead with this, and if we decide to primarily use
> a category to mark these, we will need a plan for how to manage a name
> collision conflict when there are two ports that install the same software,
> one by building from source (on newer systems) and one by installing a
> binary (on older systems).
>
> > This does not introduce any new mechanism or concept that does not
> already currently exist in MacPorts.
> >
>
> yes it does. An example: let’s take the port MacVIM, which is ripe for
> this treatment.
>
> We can build and install the current macvim on some newer systems - let’s
> say 10.12 to current.
>
> port -v install macvim gets you that.
>
> We will all know what that port represents, without trouble, if there is a
> ticket.
>
> Now say on 10.7 to 10.11, we want to install a binary version of macvim.
> macvim won't build on those systems, but there is a binary that works.
>
> We need a clear, identifiable port name to install the macvim binary. It
> should not be called macvim, that is just a *crazy* recipe for trouble.
> You’d never be able to keep up with what was what. We need the port to
> clearly be recognizable as the macvim binary.
>
> We need a new name. No trickery with categories is acceptable here.
>
> The “macvim” port might (or might not) point a user to the macvim_binary
> port if needed, but it can’t be the same port with the same name, and it
> most definitely should not install the binary instead. If we go down that
> road, we’ll never know what is going on, and this whole idea would best be
> left not done.
>
> Like
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200806/5224018e/attachment.htm>