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

[Cy Schubert]

In message <201908260229.x7Q2TMSM074266 at gndrsh.dnsmgr.net>, "Rodney W. 
Grimes"
writes:
> [ Charset UTF-8 unsupported, converting... ]
> > 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 o
> r
> > > 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.
>
> Only incompatible in mind.  $0 can easily be used to determine which
> set of getopt() to process in a single binary that then has unduplicated
> code to implement the set of final options.  A bit more to code but
> should achive the single binary linked by 2 names processing 2 different
> option sets executing 1 set of common code.
>
> I am firmyly in the camp these changes are being made to well estabilish
> and probably heavily used utility by both humans and shell scripts.
>
> I was not happy with the changes to -n, but sat silient on that issue,
> with other things being done I need to chime in and say I think that
> this is poorly tought out with respect to downstream impact.  
>
> > 
> > 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?
>
> How does a copy in ports of the old ping6 code "remove duplicate code",
> that just changes the location of the duplication out of base where it
> shall certainly rot as unmaintained causing numerious consumers heart
> ache over time.

Ports is a big issue, especially considering we're supporting previous 
versions of FreeBSD (stable/11 & stable/12) with an inconsistent ping6. 
Also agreed regarding checking *argv[0] to determine which getopt() to use.

While we're at giving ping options some love and attention, shouldn't we 
also use getopt_long()? It is 2019 for that matter, and almost 2020 in a 
few months.

>
> -- 
> Rod Grimes                                                 rgrimes at freebsd.or
> g
>


-- 
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.