Date: Sun, 25 Aug 2019 22:24:54 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: rgrimes@freebsd.org Cc: alan somers <asomers@gmail.com>, Hiroki Sato <hrs@allbsd.org>, Alan Somers <asomers@freebsd.org>, Jan Sucan <sucanjan@gmail.com>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r351423 - in head: . sbin/ping6 sbin/ping6/tests Message-ID: <201908260524.x7Q5Osnv055867@slippy.cwsent.com> In-Reply-To: <201908260229.x7Q2TMSM074266@gndrsh.dnsmgr.net> References: <201908260229.x7Q2TMSM074266@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <201908260229.x7Q2TMSM074266@gndrsh.dnsmgr.net>, "Rodney W. Grimes" writes: > [ Charset UTF-8 unsupported, converting... ] > > On Sun, Aug 25, 2019, 2:11 PM Hiroki Sato <hrs@allbsd.org> wrote: > > > > > Alan Somers <asomers@freebsd.org> wrote > > > in <CAOtMX2hLxx=SKvh1ZoiMAcagQJjPaRSvkML9J+BgpQsz5uNNbw@mail.gmail.com> > : > > > > > > as> On Sun, Aug 25, 2019 at 1:22 PM Hiroki Sato <hrs@allbsd.org> wrote: > > > as> > > > > as> > Hi, > > > as> > > > > as> > Alan Somers <asomers@FreeBSD.org> wrote > > > as> > in <201908231522.x7NFMLuJ068037@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@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@freebsd.or > g > -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201908260524.x7Q5Osnv055867>