onioncat @0.2.2.r569: binary gcat conflicts with coreutils

[l2dy (Zero King)]

The onioncat port contains gcat which conflicts with gcat in coreutils. Which resolution is preferred?

Citing mojca:

Yes. You should either:

1. Add conflicts coreutils to onioncat and conflicts onioncat to coreutils and prevent users from having both installed at the same time. (This is already the case now, but it is better to make the conflict explicit.)
2. Resolve the conflict by renaming the gcat binary.

And you should probably open a ticket.

[kurthindenburg (Kurt Hindenburg)]

onioncat's gcat is just a link to its ocat binary - do you know if any software that calls gcat expecting it to be gcat? I'd think removing this link would be the simplest approach.

[mojca (Mojca Miklavec)]

l2dy: I just wanted to say that the decision is yours because you are the maintainer (and hopefully the user). We cannot decide instead of you if we don't even know how the software is supposed to work unless there are other users around. One of committers can only commit your proposal.

It might also make sense to bring this question upstream, warn the developers that "gcat" exists elsewhere (I guess it's "gnu cat") and let us know their response. It makes more sense if upstream decides how to handle such conflicts that if we do things that are incompatible to the way the software is used elsewhere.

(Kurt's suggestion to remove gcat if it's only a symlink makes sense to me. Maybe gcat is there for backward compatibility only?)

[l2dy (Zero King)]

gcat is effectively ocat -I (-I GarliCat mode, use I2P instead of Tor). I'd go for the simple approach and remove the symlink.

[l2dy (Zero King)]

In 809ca2b2/macports-ports:

onioncat: delete gcat

Closes: #53183