Remove +with_default_names and use a specific path for unprefixed binaries

[Ryan Schmidt]

On Sep 18, 2009, at 01:44, Bryan Blackburn wrote:

> Are you willing to build all 6100+ ports to verify all of them are  
> okay with
> +with_default_names?
>
> Also, note that some of these ports are dependencies for other  
> ports, so it
> may not simply be a case of "you wanted it, so you must want it as the
> default".  For example, I have m4 and gsed installed solely as  
> dependencies,
> and I believe that's how I've ended up with coreutils before.

Exactly. I don't have gsed because I want gsed; I have it because php5  
requires it. That is, php5 doesn't require it; it would work fine with  
bsd sed. But if gsed is present, php5 encodes the name "gsed" into one  
of its scripts; if I were to uninstall gsed later, a part of php5  
would break. Once I realized that, I had to either add the dependency  
or patch php5. The former was easier and more future-proof than the  
latter.

Mark brought the with_default_names issue up with me a few weeks ago  
and I convinced him that putting the unprefixed binaries into $ 
{prefix}/libexec/something would be an ok solution. I, too, would like  
to get rid of the with_default_names variants, but having the software  
install with default names always is not acceptable for the reasons  
mentioned. It would break tons of stuff. I presume that is the reason  
why e.g. gsed was changed to not install that way by default over four  
years ago in r13825. We don't want to re-break what that fixed.

I'm not sure what "something" in ${prefix}/libexec/something should  
be. I suggested ${name} because that's what other ports use. Mark  
suggested "gnubin". "gnubin" would be convenient in that you would  
only have to add one path to your PATH to pick up all installed GNU  
utilities. On the other hand, might there be a reason when you would  
want only specific GNU utilities and not others? Might you want to  
only have the GNU sed and keep the BSD awk, say? If so, then putting  
each port's binaries in its own directory would give you that freedom.  
Heck, we could have it both ways: each port could create two symlinks  
to each program, one in ${prefix}/libexec/gnubin and one in ${prefix}/ 
libexec/${name}. Then the user can use whichever path they like.