port "cask" -- installing prebuilt binaries

[Ken Cunningham]

> On Aug 6, 2020, at 12:28 PM, Herby G <herby.gillot at gmail.com> wrote:
> 
> > so far, name-suffix is winning on all fronts...with no downsides yet.
> 
> I don't plan on pushing the issue, but I have to say that I don't agree.
> 
> Using a name suffix isn't clean, as you may include other non-binary ports that may happen to have the word "binary" in their name.
> 
> A category allows you a cleaner approach as you can now represent that a port is binary as an _attribute_ of the port, rather than overloading the name.
> 
> This will make it easier to write port utilities and commands that target binary ports.
> 
> We can easily add an alias that could let you do things like "port -v binary_only" which would transparently do the "category:binary".
> 
> Additionally, if using a category, you can see the list of binary ports in a clean way when browsing ports in the MacPorts website, it makes it easier to do things like add an icon to signify binary only if a given port is in the "binary" category, and not make possibly mistaken assumptions off of the name.
> 
> On Thu, Aug 6, 2020 at 3:02 PM Ken Cunningham <ken.cunningham.webuse at gmail.com <mailto:ken.cunningham.webuse at gmail.com>> wrote:
> category-only identifier is
> 
> less clear and less obvious
> harder to remember how to search for
> name conflicts with a non-binary version (eg for newer systems that can build it)
> 
> so far, name-suffix is winning on all fronts...with no downsides yet.
> 
> K


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).

I would suggest the binary install version of the port be called “portname_binary” unless someone has a better idea for how to manage this issue.

Ken


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200806/c5bdac28/attachment.htm>