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

[Warner Losh]

On Sun, Aug 25, 2019, 10:35 PM Jan Sucan <sucanjan at gmail.com> wrote:

> Hello,
>
> I can implement it. I suppose that ping6's manual page should be kept it
> this case.
>

The differences are small enough you may be able to combine man pages.

I was also thinking about printing a warning for each option renamed to
> lead a willing user to use the new unified option set of ping. It could
> be either only with -v, or by default and suppressed with -q. Or should
> the option translation be completely transparent?
>

This I'm unsure about., so I'll leave it to others to opine.

Warner

-Jan
>
> On 26. 8. 2019 1:58, Alan Somers wrote:
> > 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?
>
>
>