Add backward compatibility for fping6 sym-link

[abelbeck]

Adding a sym-link for fping6 is not quite enough to satisfy old scripts, -6 must also be implied.

[coveralls]

Coverage decreased (-0.1%) to 79.57% when pulling a82f40f on abelbeck:fping6 into 180c6dd on schweikert:develop.

[schweikert]

Using sym-links is a bit flawed, because it won't work for IPv4 (where you don't use "fping4"). The suggestion is to use differently compiled binaries, if compatibility is needed.

[abelbeck]

Hi @schweikert

fping6 occurs in user generated scripts, and we need to support it in our (AstLinux) project.

A single sym-link (fping6 -> fping) and 3 lines of code (this PR) solves the problem.

I looked at Debian for reference, and for versions that support fping 4.x, they also install a fping6 -> fping sym-link, but without this PR fping6 would not behave the same as fping6 3.x did.

I would argue that this PR causes no harm and adds support for fping6 3.x functionality if the sym-link was installed. It seems a waste to compile a separate binary for this case.

[schweikert]

The "harm" is that it gives the false impression that you can solve the compatibility requirement by using a symlink. That seems to work with fping as well, but it can give surprises (i.e. when a site becomes reachable also via ipv6).

[abelbeck]

I'm only talked about fping6 ... and making it map to fping -6 ...

Is there a case when this would not work as expected ?

[schweikert]

I am trying to understand, sorry :)

What is the use case to have a fping6 binary doing only IPv6 and a fping binary doing IPv4+IPv6?

[abelbeck]

It all about backward compatibility and supporting fping6 in other people's scripts created pre-4.x .

There is only a need for one binary fping, a fping6 -> fping sym-link and this PR. which results in the proper output, for example:

# fping6 -Aa www.google.com
2607:f8b0:4007:804::2004

Without this PR and with a sym-link (as Debian does), the result:

# fping6 -Aa www.google.com
172.217.14.68

[schweikert]

I feel like you are not really hearing out what I am trying to say. If you use a fping6 binary that only does IPv6, aren't you also going to use a fping binary for IPv4?

Or let me put it this way: maybe you should also add similar code and imply "-4" if the binary matches "fping4" ?

[abelbeck]

There is no fping6 binary, only a fping6 sym-link. The only binary is fping.

Or let me put it this way: maybe you should also add similar code and imply "-4" if the binary matches "fping4" ?

There was never a fping4 binary or sym-link installed with 3.x and earlier, was there ? If there was never a reason scripts would include fping4 then no reason to support it now. But if fping4 did exist then to answer your question, yes - sure.

[schweikert]

This means that when you use this symlink technique, scripts that use fping for IPv4 and fping6 for IPv6 (i.e. assuming fping < 3.0), will seem to work correctly, but effectively deliver sometimes wrong results for IPv4 (because fping will do IPv4+IPv6). That doesn't seem like a good idea to me.

[abelbeck]

This means that when you use this symlink technique, scripts that use fping for IPv4 and fping6 for IPv6 (i.e. assuming fping < 3.0), will seem to work correctly

I agree.

but effectively deliver sometimes wrong results for IPv4 (because fping will do IPv4+IPv6). That doesn't seem like a good idea to me.

Well, we don't have a time machine :-) So fping now being both 4/6 is what it is. I think most will count this as "progress" and move on. I don't think you want fping to default to -4 (as 3.x) and require an option for dual-stack mode.

At least with this PR a fping6 sym-link will work the same as included in 3.x.

[abelbeck]

Thank you!