port "cask" -- installing prebuilt binaries

[Ruben Di Battista]

I also believe we should apply this strategy to "binary only" non-open
source software.

I have a question tho, probably addressed mostly to @Ken and those that
manage the ports builds on old systems, in facts, about hybrid ports (as
defined by @Herby: open source software that we are unable to build on some
systems and then we ship it as binary only).

If they've been built somewhere by the upstream developer, shouldn't we be
able to build them too and hence instead of providing them as binaries we
would  fix the ports in order to build on old systems? I guess it's a
matter of how hard is to fix the build environment on old systems...


On Fri, 7 Aug 2020, 03:56 Herby G, <herby.gillot at gmail.com> wrote:

> 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/20200807/7dddfed4/attachment-0001.htm>