Name conflict with inetutils on macOS

[rpdelaney]

inetutils provides (among other things) GNU ping, symlinked as gping:

$ gping --version
ping (GNU inetutils) 1.9.4
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Sergey Poznyakoff.

Thus there is a naming conflict when gping is installed with homebrew:

$ brew install gping
# snip
==> Pouring gping-0.1.7.catalina.bottle.tar.gz
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink bin/gping
Target /usr/local/bin/gping
is a symlink belonging to inetutils. You can unlink it:
  brew unlink inetutils

To force the link and overwrite all conflicting files:
  brew link --overwrite gping

To list all files that would be deleted:
  brew link --overwrite --dry-run gping

Possible conflicting files are:
/usr/local/bin/gping -> /usr/local/Cellar/inetutils/1.9.4_2/bin/gping
==> Summary
🍺  /usr/local/Cellar/gping/0.1.7: 7 files, 2MB

I wouldn't suggest that gping should be renamed to account for this corner case. But some guidance would be appreciated for those of us who would like to maintain access to both tools.

[kidonng]

This is a Homebrew issue, not inetutils or macOS (one will still encounter this with Linuxbrew). Homebrew prefix the tools with a g to prevent shadowing existing tools on macOS. Probably adding a caveats block to gping's Homebrew formula will ease the confusion.

[orf]

Argh. Yeah, there isn't much I can do here. It's an unfortunate naming collision, I'll add a caveat to the formula when I do a bump next.

[djmattyg007]

Why not just rename the binary in the relevant formula? Similar to how some Linux distros rename the fd binary to fd-find to avoid a naming collision.

[harens]

This issue was recently raised over at MacPorts, where I maintain the gping port: https://trac.macports.org/ticket/63168

This is a Homebrew issue, not inetutils or macOS (one will still encounter this with Linuxbrew). Homebrew prefix the tools with a g to prevent shadowing existing tools on macOS.

I don't think it's a Homebrew-specific issue, since I presume other BSD-based systems will also have the same conflict. The g is just there to note that it's a GNU tool, and this is fairly standard on other BSD package managers. The most popular example of this being the coreutils package.

I agree with @orf that the only feasable option is to note in each relevant package manager that the two conflict with each other. I will be sure to do that for MacPorts at some point.

(By the way, thanks @orf and the other contributors for putting your time and effort into maintaining this amazing tool! 👍)

[orf]

@harens is there any way I can update macports automatically when I do a new release? I use this CI action (https://github.com/mislav/bump-homebrew-formula-action) for homebrew.

[harens]

@orf I'm sorry I haven't been keeping the port up-to-date recently. That's totally my fault :) I've just bumped it now https://github.com/macports/macports-ports/commit/af18e6804687623a8e7c3c1d331938fd8ed77dbd.

@harens is there any way I can update macports automatically when I do a new release? I use this CI action (https://github.com/mislav/bump-homebrew-formula-action) for homebrew.

Not really. The main reason why is since gping's dependencies are manually specified using a tool called cargo2port. MacPorts takes reproducible builds very seriously, and specifying which dependencies should be installed before building gping helps with this.

Case in point, the latest 1.2.7 release introduces build timestamps, which is a big source of reproducibility problems. I therefore manually set the time to that of the last file modification.

---

I have some basic automation setup on my side, so it is very easy for me to update gping (~5 mins). I'll try and update the port more quickly in the future.

[eugenesvk]

@harens is there a way for the macports version to not force the inconvenient binary name and instead just note that there is a potential for conflict?

[harens]

@eugenesvk It makes sense to resolve the conflict. Inetutils includes really common network tools, and so people do indeed use them alongside gping.

Off the top of my head, the easiest thing for you might be just to set an alias: alias gping='graphping'

[eugenesvk]

it only makes sense for those people who have a conflict :) I just thought maybe MacPorts had a better mechanism, e.g., only renaming if there is a conflict instead of preemptively since alias now has to be platform-specific, which is not a big deal, but worse than a better conflict resolution within the package manager

[harens]

e.g., only renaming if there is a conflict instead of preemptively since alias now has to be platform-specific

You're right that would be ideal. I'm not aware of any package managers that implement this, but it might be possible. Something to think about :) Thanks @eugenesvk.