port "cask" -- installing prebuilt binaries

[Ruben Di Battista]

So my take here is to not provide pre-built binaries packages if not
strictly unavoidable, like for the osxfuse project (since it was open
source before).

One of the reasons I chose Macports for is the fact it builds its own tree
from source and it ships basically open source only software.

Otherwise there would be no difference with homebrew and it would make
little sense to prefer Macports UX, that is arguably worse than Homebrew's
IMHO (especially Ruby DSL formula vs TCL Portfile).

On Tue, 4 Aug 2020, 19:47 Ruben Di Battista, <rubendibattista at gmail.com>
wrote:

> There's is one compelling need for having "binary only" install, and that
> is for the port "osxfuse", that is currently broken for 10.14+.
>
> There was a discussion about it on the Github project about the choice of
> making it close closed source... Nonetheless it would be useful to have it
> in order to provide things like fuse file systems and so on.
>
>
>
> On Tue, 4 Aug 2020, 15:38 Lothar Haeger, <lothar.haeger at gmx.net> wrote:
>
>>
>>
>> Am 30.07.2020 um 08:03 schrieb Ken Cunningham <
>> ken.cunningham.webuse at gmail.com>:
>>
>> I only raise the idea as people are already doing this, and submitting such ports, and before we have too many, there is an opportunity to say how it should best be done (custom category, naming convention, etc).
>>
>> Reminds me of an earlier conversation at
>> https://github.com/macports/macports-ports/pull/6767#discussion_r402584006
>>
>>
>> I do see some benefits is formalizing binary-only ports and to adapt the
>> build and distribution scheme for it. Could save resources and development
>> time and make those ports easily recognizable for those who care about the
>> different way it was built.
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200804/44538eba/attachment.htm>