Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#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 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 7 years ago by blair (Blair Zajac)

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

comment:2 Changed 7 years ago by ryandesign (Ryan Schmidt)

  • Cc ryandesign@… added

Cc Me!

comment:4 Changed 7 years ago by tobypeterson

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

comment:5 Changed 7 years ago by blair (Blair Zajac)

Shell aliases don't work in scripts.

comment:6 Changed 7 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:7 Changed 7 years ago by jabronson@…

  • Cc jabronson@… added

Cc Me!

comment:8 Changed 7 years ago by skymoo (Adam Mercer)

  • Cc ram@… added

Cc Me!

comment:9 Changed 7 years ago by mark@…

  • Cc mark@… added

Cc Me!

comment:10 Changed 7 years ago by blb@…

mww updated gnutar in r57932.

comment:11 follow-up: Changed 7 years ago by mww@…

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

comment:12 Changed 7 years ago by vinc17@…

  • Cc vinc17@… added

Cc Me!

comment:13 in reply to: ↑ 11 ; follow-up: Changed 7 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 in reply to: ↑ 13 Changed 7 years ago by ryandesign (Ryan 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:15 Changed 7 years ago by kenyon@…

  • Cc kenyon@… added

Cc Me!

comment:16 Changed 7 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 7 years ago by ryandesign (Ryan Schmidt)

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

comment:18 Changed 6 years ago by jmroot (Joshua Root)

  • Resolution set to fixed
  • Status changed from new to closed

comment:19 Changed 6 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 6 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 6 years ago by blair (Blair Zajac)

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

Note: See TracTickets for help on using tickets.