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

[Alan Somers]

Jan (please keep him CCed on replies) has been musing about the same
thing.  That might satisfy everyone.  Jan, would it be straightforward
to implement?
-Alan

On Sun, Aug 25, 2019 at 5:51 PM Conrad Meyer <cem at freebsd.org> wrote:
>
> 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?