On Sun, Jul 26, 2026 at 3:36 PM Martin Kalčok <[email protected]> wrote:
> Hi Ihar, > Thanks for the patch. This "traditional nc" vs "nmap nc" brings up > memories from when I first started with OVN, so I thought I'll chime > in. > > The Joy of Unix compatibility. :) > On Sun, Jul 26, 2026 at 8:08 PM Ihar Hrachyshka > <[email protected]> wrote: > > > > Nmap names and installs its netcat implementation as ncat. Its Makefile > > installs the ncat executable and does not create an nc link. Ubuntu and > > Fedora provide nc through packaging alternatives, whereas the NixOS > > Nmap package exposes the upstream executable name. Consequently, OVN > > reports HAVE_NC=no and cannot run its netcat-based system tests there. > > > > Prefer ncat when it is available and retain nc as a fallback for systems > > which provide the compatibility name or another supported netcat > > implementation. Route all invocations through the command selected by > > the feature probe. > > > > The tests use several Ncat-specific options, which is why the upstream > > Nmap name is the first choice rather than merely accepting whichever > > netcat command appears first in PATH. > > > > Assisted-by: Codex gpt-5.6-sol high > > Signed-off-by: Ihar Hrachyshka <[email protected]> > > --- > > tests/atlocal.in | 15 +- > > tests/system-common-macros.at | 10 +- > > tests/system-ovn-kmod.at | 90 +++---- > > tests/system-ovn.at | 472 +++++++++++++++++----------------- > > 4 files changed, 298 insertions(+), 289 deletions(-) > > > > diff --git a/tests/atlocal.in b/tests/atlocal.in > > index 2683e9a2f..40635266f 100644 > > --- a/tests/atlocal.in > > +++ b/tests/atlocal.in > > @@ -135,11 +135,20 @@ find_command() > > fi > > } > > > > -# Set HAVE_NC > > -find_command nc > > +# Set HAVE_NC and select the installed netcat command. > > +if command -v ncat > /dev/null 2>&1; then > > + NC=ncat > > + HAVE_NC=yes > > +elif command -v nc > /dev/null 2>&1; then > > + NC=nc > > + HAVE_NC=yes > > +else > > + NC=nc > > + HAVE_NC=no > > +fi > > As you noted above, both Ubuntu and Fedora use links via > "/etc/alternatives" to expose "ncat" as "nc", but they also retain the > "ncat" > > Ubuntu 24.04: > $ which ncat > /usr/bin/ncat > > Fedora 43: > $ which ncat > /usr/sbin/ncat > > Given that many tests rely on ncat-specific features, wouldn't it be > better to check only for presence of "ncat" and set `HAVE_NC=no` if it > doesn't exist? > > Best regards, > Martin. > > This is an interesting observation. I think OVN inherited HAVE_NC from OVS where actual compatibility with non-nmap nc(at) implementations was historically maintained (and - for what I gather from my brief reading of the current OVS trunk tests - still is largely retained, though there was some drift there too). Since then, some OVN tests have adopted unique nmap ncat features, disregarding compatibility with alternative `nc` implementations. So now we are here. And we have a few options: a) retain the historical generic-nc fallback, even though it no longer works for the entire test suite (the approach taken by this patch); or b) accept that the suite now effectively depends on ncat and make the feature check reflect the reality. Reflecting reality could mean mapping HAVE_NC to `ncat`. Or perhaps just run `find_command ncat` and use the resulting `HAVE_NCAT` as the feature flag. (Then drop `HAVE_NC` usage.) There's also a hybrid solution: try to separate tests that are still genuinely `nc`-compatible from those `ncat`-specific, and use both `HAVE_NC` and `HAVE_NCAT` in testthe suite. Whether this chore and ongoing maintenance of the split is worth it... I will let the maintainers decide. :) A lazy me would be happy to stick to the existing patch (a), a nerdy me would be happy to send a patch for (b) instead. Let me know what's preferred. Ihar _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
