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.
