> On Aug 6, 2020, at 12:28 PM, Herby G <herby.gil...@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.web...@gmail.com <mailto:ken.cunningham.web...@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


Reply via email to