I propose we create an eselect module that manages the /usr/bin/nc symlink between the above for whichever of them are installed. (net-analyzer/netcat, i should think, shouldn't need to be part of the module as it blocks the other three from what i recall. someone check me on this?) currently, there are several netcat iterations available in portage, all of which have their strengths and weaknesses: net-analyzer/nmap (installs /usr/bin/ncat) net-analyzer/gnu-netcat (installs /usr/bin/netcat) net-analyzer/netcat6 (installs /usr/bin/nc6, and currently the /usr/bin/nc symlink points to this) However, this can affect shell script portability between different systems due to each iteration having several differences (for instance, the -t switch: net-analyzer/gnu-netcat specifies TCP, net-analyzer/nmap specifies telnet negotiations, and net-analyzer/netcat6 specifies idle timeout. i believe the original unix netcat (nc) implementation uses -t for telnet negotiations, as ncat does). This can lead to a more flexible system, as users can decide which implementation to call nc under. (Granted, I'm sure users can set an alias in their shell .file, but I am under the impression that implementing this as an eselect module is moreso the Gentoo Way). Reproducible: Always Steps to Reproduce: (N/A) Actual Results: (N/A)
I second this...Presently, I cannot (easily) merge libvirt because it depends upon netcat6...which I've had to mask because I require a different version of netcat. eselect sure would fit the bill here...
In my opinion nc should *ALWAYS* be gnu netcat as that is what scripts should be expecting. I would be interested in potentially completely removing the symlink though, I'm not thrilled with the way things are now either but I think an eselect would do more harm than good as these are NOT compatible with each other. Thoughts?
This isn't going to work as you intended it, I guess.
