From owner-svn-src-head@freebsd.org Sun Aug 25 23:58:51 2019 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1BC58C9677; Sun, 25 Aug 2019 23:58:51 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46GsY66sJlz4ddf; Sun, 25 Aug 2019 23:58:50 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f196.google.com with SMTP id z17so13451414ljz.0; Sun, 25 Aug 2019 16:58:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6BmYDSqs/dXRXvkMWiM4xPxNtftCpzZ4ksrp9M3VeEw=; b=RUWA9AvOsKHztUYGP8K3Jj9xYuywI9aCh/R2xMlaQG//m1k/gP5zhpXpuknOtWTR3v pNkAAlLJ6OIV54oLfR5M9gdzW1ece9Qen5Ipup2uD8Srv91p9n23+u0r26t5vWeemyza wDUndcZTYH/ZlA4+VAy/y1q3QrgSy2aKQN+M8adCLuMM/qXHZFykMwltAVr6lbvL2jRh U9c0vNmHyHSHn0cn0MqZOsxLxopKbnb8UITL+LWVy3gWqAqRIWzb86on1qbvKFioStot znL3InLyPYOtbA+1aVlV+SQ6nEpTEKb6teF6stHalur7ahSpe0IieebELtHs0FuA4q8O 6jpQ== X-Gm-Message-State: APjAAAWPhrUwHgrnnpCO0I2m64IzcaBvKKzYPKVyb7bM79SvN0bf8i8I jj2hm4Gzn+ond+p7vIcYf0jvg/xZxbwN4YgEWFPi68Kt X-Google-Smtp-Source: APXvYqxoBVeT4Qf2ippp4EnCrmitH3ojYrKgXr5qNbp5S2F3wjNZBh41RIw6AkryAxTjHH9BkQmq5KN7L+764oLmbpQ= X-Received: by 2002:a2e:a0c3:: with SMTP id f3mr8998688ljm.123.1566777528702; Sun, 25 Aug 2019 16:58:48 -0700 (PDT) MIME-Version: 1.0 References: <201908231522.x7NFMLuJ068037@repo.freebsd.org> <20190826.042056.1329861772202588895.hrs@allbsd.org> <20190826.050922.1810654532466043358.hrs@allbsd.org> In-Reply-To: From: Alan Somers Date: Sun, 25 Aug 2019 17:58:37 -0600 Message-ID: Subject: Re: svn commit: r351423 - in head: . sbin/ping6 sbin/ping6/tests To: "Conrad E. Meyer" , Jan Sucan Cc: Hiroki Sato , src-committers , svn-src-all , svn-src-head Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 46GsY66sJlz4ddf X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.982,0] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 23:58:51 -0000 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 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 =E2=80=94 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 wrote: > > > > On Sun, Aug 25, 2019, 2:11 PM Hiroki Sato wrote: > >> > >> Alan Somers wrote > >> in : > >> > >> as> On Sun, Aug 25, 2019 at 1:22 PM Hiroki Sato wrote= : > >> as> > > >> as> > Hi, > >> as> > > >> as> > Alan Somers 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 nonequival= ent options have > >> as> > as> different flags. This is a prelude to merging the two com= mands. > >> as> > as> > >> as> > as> Submitted by: J=C3=A1n Su=C4=8Dan > >> as> > as> MFC: Never > >> as> > as> Sponsored by: Google LLC (Google Summer of Code 2019) > >> as> > as> Differential Revision: https://reviews.freebsd.org/D213= 45 > >> as> > > >> as> > I have an objection on renaming the existing option flags in pi= ng6(8) > >> as> > for compatibility with ping(8). > >> as> > > >> as> > Is it sufficient to add INET6 support to ping(8) with consisten= t > >> as> > flags and keep CLI of ping6(8) backward compatible? People hav= e 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 "pin= g ::1" > >> as> > works. > >> as> > > >> as> > -- Hiroki > >> as> > >> as> If ping works with inet6, then why would we want to keep a separat= e > >> as> tool around? If it's just for the sake of people who don't want t= o 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. A= nd we can't keep ping6 around while also removing duplicate code because th= at 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 obvi= ous reminder that scripts will need updating. I think that putting a versi= on of ping6 in ports should be a sufficient crutch for those who need it, d= on't you?