> On Aug 6, 2020, at 2:34 PM, Herby G <herby.gil...@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
