On Mon, Sep 21, 2026, at 06:46, David Uhden Collado wrote:
> Giving these implementations a different prefix and avoiding symlinks 
> with the GNU-compatible names would certainly prevent conflicts. The 
> downside is that it would also make them less convenient for people who 
> actually want to use them as drop-in alternatives and test whether they 
> work for their specific use case.
>
> For an experimental package, I think there is some value in making that 
> kind of testing straightforward, as long as the user is explicitly 
> choosing the alternative implementation and understands that 
> compatibility may not yet be complete.

Hard disagree from me. (Acknowledging that I'm a newbie here and that my words don't - and shouldn't - carry the weight that somebody like Theo de Raadt's have.)

An experimental package should go out of its way to not create unexpected breakage. If somebody wants to play around with such a package, good luck to them. They can set up their environment as they see fit. But if somebody is installing a package out of curiosity, without knowing exactly what it is, it should not break their system. The friction should be in the direction of those expecting it: the person who goes out of their way to test an experimental package.

When it comes to core utilities, I think erring on the side of safety is the right way to go - meaning that experimental packages that replace known stable and reliable tools should install themselves out of the way, and require active intervention from the end user to become the default.

This is completely separate to the question of whether experimental packages even belong in ports. I can see some potential value in maybe having the source in the tree so that people can build them if they want them, but I'm seriously uncomfortable with the idea of building them and making them available by default.