svn commit: r351423 - in head: . sbin/ping6 sbin/ping6/tests

[Conrad Meyer]

Hi Alan, Hiroki,

It would be pretty easy to install a `ping6` link to the `ping(8)`
binary with different option parsing (conditional on argv[0]).  That
removes most of the issues of code and space duplication, I think?
And the goal would be for the 'ping6' name to retain option
compatibility with historical ping6.

It's not an uncommon pattern; for example, 'id', 'groups', and
'whoami' are all a single binary with multiple linked names.  Another
example is Clang, which provides 'cc', 'c++', 'clang', 'clang-cpp',
'clang++' and 'cpp' links to the same inode — and those have very
different behavior depending on argv[0].

It's less work than forcing the ping6 compatibility crowd to create a
port and doesn't hurt ping(8) much, AFAICT.  Is it an acceptable
middle ground?

Best,
Conrad

On Sun, Aug 25, 2019 at 1:26 PM alan somers <asomers at gmail.com> wrote:
>
> On Sun, Aug 25, 2019, 2:11 PM Hiroki Sato <hrs at allbsd.org> wrote:
>>
>> Alan Somers <asomers at freebsd.org> wrote
>>   in <CAOtMX2hLxx=SKvh1ZoiMAcagQJjPaRSvkML9J+BgpQsz5uNNbw at mail.gmail.com>:
>>
>> as> On Sun, Aug 25, 2019 at 1:22 PM Hiroki Sato <hrs at allbsd.org> wrote:
>> as> >
>> as> > Hi,
>> as> >
>> as> > Alan Somers <asomers at FreeBSD.org> wrote
>> as> >   in <201908231522.x7NFMLuJ068037 at repo.freebsd.org>:
>> as> >
>> as> > as> Author: asomers
>> as> > as> Date: Fri Aug 23 15:22:20 2019
>> as> > as> New Revision: 351423
>> as> > as> URL: https://svnweb.freebsd.org/changeset/base/351423
>> as> > as>
>> as> > as> Log:
>> as> > as>   ping6: Rename options for better consistency with ping
>> as> > as>
>> as> > as>   Now equivalent options have the same flags, and nonequivalent options have
>> as> > as>   different flags.  This is a prelude to merging the two commands.
>> as> > as>
>> as> > as>   Submitted by:     Ján Sučan <sucanjan at gmail.com>
>> as> > as>   MFC:              Never
>> as> > as>   Sponsored by:     Google LLC (Google Summer of Code 2019)
>> as> > as>   Differential Revision:    https://reviews.freebsd.org/D21345
>> as> >
>> as> >  I have an objection on renaming the existing option flags in ping6(8)
>> as> >  for compatibility with ping(8).
>> as> >
>> as> >  Is it sufficient to add INET6 support to ping(8) with consistent
>> as> >  flags and keep CLI of ping6(8) backward compatible?  People have used
>> as> >  ping6(8) for >15 years, so it is too late to rename the flags.  I do
>> as> >  not think the renaming is useful if "ping -6 localhost" or "ping ::1"
>> as> >  works.
>> as> >
>> as> > -- Hiroki
>> as>
>> as> If ping works with inet6, then why would we want to keep a separate
>> as> tool around?  If it's just for the sake of people who don't want to or
>> as> can't update scripts, would a version in ports suffice?
>>
>>  Because removing (or renaming) it causes a POLA violation.  Do we
>>  really have a strong, unavoidable reason to force people to rewrite
>>  their script now?  This is still a fairly essential and actively used
>>  tool, not like rcp or rlogin.  Although deprecating ping6(8) and
>>  removing it from the base system in the future release at some point
>>  may work, changing the existing interface will simply confuse people
>>  who have used IPv6 for a long time.
>>
>>  In my understanding, the purpose to integrate ping(8) and ping6(8)
>>  into a single utility is to provide a consistent CLI and reduce
>>  duplicate code, not to break compatibility.
>>
>> -- Hiroki
>
>
> Those goals are incompatible. We can't provide a consistent CLI without breaking compatibility because ping and ping6 have conflicting options.  And we can't keep ping6 around while also removing duplicate code because that would be, well, duplicate code.
>
> When would be a better time than a major version bump to make a change like this?
>
> The lack of a ping6 command in freebsd 13 should serve as a pretty obvious reminder that scripts will need updating.  I think that putting a version of ping6 in ports should be a sufficient crutch for those who need it, don't you?