#20748 closed enhancement (fixed)
Remove +with_default_names and use a specific path for unprefixed binaries
Reported by: | blb@… | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | gnu | Cc: | mww@…, blair (Blair Zajac), fracai, nox@…, ryandesign (Ryan Carsten Schmidt), jabronson@…, skymoo (Adam Mercer), mark@…, vinc17@…, kenyon@… |
Port: | gnutar m4 gnetcat coreutils diffutils findutils gwhich gsed |
Description
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.
Change History (21)
comment:1 Changed 15 years ago by blair (Blair Zajac)
comment:4 Changed 15 years ago by tobypeterson
Why not just instruct users to make appropriate shell aliases if they so desire?
comment:6 Changed 15 years ago by tobypeterson
Seems to me that, if you're using a script and want the GNU junk, you should have to modify the script.
comment:11 follow-up: 13 Changed 15 years ago by mww@…
As discussed on macports-dev@, we will use ${prefix}/libexec/gnubin
as the directory for un-prefixed GNU executables.
comment:13 follow-up: 14 Changed 15 years ago by 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?
comment:14 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)
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.
comment:16 Changed 15 years ago by 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.
comment:17 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)
comment:18 Changed 14 years ago by jmroot (Joshua Root)
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:19 Changed 14 years ago by blair (Blair Zajac)
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?
comment:20 Changed 14 years ago by 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.
comment:21 Changed 14 years ago by blair (Blair Zajac)
Thanks, that did it. I bumped autoconf's revision in r73682 so no one else has this issue.
Let's discuss this on the mailing list first before implementing it.