Date: Sun, 25 Aug 2019 19:29:22 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: alan somers <asomers@gmail.com> Cc: 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: <201908260229.x7Q2TMSM074266@gndrsh.dnsmgr.net> In-Reply-To: <CAOtMX2jhmV%2BqRH%2BU1jMzdXsnckAvkzJhQiU6H65jUjdpK%2BXU3Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ 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 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. 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. -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201908260229.x7Q2TMSM074266>