> 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