Remove +with_default_names and use a specific path for unprefixed binaries

[blb@…]

Several ports have the +with_default_names variant to provide binaries which aren't prefixed by g (or similar). This has caused issues over time (the ones in MacPorts' base should be mostly fixed in 1.8.0) including some ports failing to build properly (#19431 and #20275 found with a quick search).

Instead of +with_default_names I propose we always install the g-prefixed versions in ${prefix}/bin (as would happen without +with_default_names), but also install the unprefixed versions into a special bin path for such things. For example, ${prefix}/gnubin could be used. Then anyone who really wants these binaries to override their system equivalents would simply need to add ${prefix}/gnubin to their PATH, but anything else build with port would not see them.

[blair@…]

Let's discuss this on the mailing list first before implementing it.

[ryandesign@…]

Cc Me!

[blb@…]

 The start of the thread on -dev.

[toby@…]

Why not just instruct users to make appropriate shell aliases if they so desire?

[blair@…]

Shell aliases don't work in scripts.

[toby@…]

Seems to me that, if you're using a script and want the GNU junk, you should have to modify the script.

[jabronson@…]

Cc Me!

[ram@…]

Cc Me!

[mark@…]

Cc Me!

[blb@…]

mww updated gnutar in r57932.

[mww@…]

As discussed on macports-dev@, we will use ${prefix}/libexec/gnubin as the directory for un-prefixed GNU executables.

[vinc17@…]

Cc Me!

[vinc17@…]

Replying to mww@…:

As discussed on macports-dev@, we will use ${prefix}/libexec/gnubin as the directory for un-prefixed GNU executables.

IMHO, this choice would not be a good idea, because ${prefix}/libexec and its subdirectories shouldn't be in the user's path. Also this wouldn't solve the problem of man pages. How about ${prefix}/gnu/bin and ${prefix}/gnu/share/man for the binaries and the man pages respectively?

[ryandesign@…]

We have been discussing several possibilities in the thread on the mailing list.

Replying to vinc17@…:

IMHO, this choice would not be a good idea, because ${prefix}/libexec and its subdirectories shouldn't be in the user's path.

Why would this be a problem?

Also this wouldn't solve the problem of man pages. How about ${prefix}/gnu/bin and ${prefix}/gnu/share/man for the binaries and the man pages respectively?

We discussed this possibility. I think it's ok with me. It has the possible disadvantage of violating the mtree.

[kenyon@…]

Cc Me!

[nox@…]

So… when do we do the move? We may want to create a GNU port group which would handle the creation of the various symlinks itself.

[ryandesign@…]

Let's make the change now. This variant is causing too many bizarre problems. (#21060, #21149, #24118)

[jmr@…]

r73585

[blair@…]

I'm unable to compile the new coreutils:

--->  Configuring coreutils
autoreconf: Entering directory `.'
autoreconf: running: autopoint --force
Copying file build-aux/config.rpath
Copying file m4/glibc2.m4
Copying file m4/iconv.m4
Copying file m4/intdiv0.m4
Copying file m4/intl.m4
Copying file m4/intldir.m4
Copying file m4/intmax.m4
Copying file m4/lcmessage.m4
Copying file m4/printf-posix.m4
Copying file m4/uintmax_t.m4
Copying file m4/visibility.m4
Copying file po/Makefile.in.in
Copying file po/Makevars.template
autoreconf: running: aclocal --force -I m4
autom4te: need GNU m4 1.4 or later: /opt/local/bin/m4
aclocal: /opt/local/bin/autom4te failed with exit status: 1
autoreconf: aclocal failed with exit status: 1
shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_sysutils_coreutils/work/coreutils-8.5" && autoreconf --install -fvi " returned error 1
Error: Target org.macports.configure returned: autoreconf failure: shell command failed

The error is odd in that the system's m4 is 1.4.6. Any idea what's going on?

[kirk.kelsey@…]

If you installed autoconf (which includes autom4te) when m4 was still in /opt/local/bin/ it won't be able to find it now in /opt/local/libexec/gnubin. Reinstalling autoconf should take care of the problem.

[blair@…]

Thanks, that did it. I bumped autoconf's revision in r73682 so no one else has this issue.