From owner-svn-src-all@freebsd.org Mon Aug 26 09:10:23 2019 Return-Path: Delivered-To: svn-src-all@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 BA872D5628; Mon, 26 Aug 2019 09:10:23 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46H5nV5BbWz47Px; Mon, 26 Aug 2019 09:10:21 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id EBC278D4A13E; Mon, 26 Aug 2019 08:59:51 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id D97D4E7088C; Mon, 26 Aug 2019 08:59:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id VkL5k9jmMkFk; Mon, 26 Aug 2019 08:59:47 +0000 (UTC) Received: from [192.168.2.110] (unknown [IPv6:fde9:577b:c1a9:31:6cf4:379e:a51d:13c3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id CCDC6E70824; Mon, 26 Aug 2019 08:59:46 +0000 (UTC) From: "Bjoern A. Zeeb" To: "alan somers" Cc: "Hiroki Sato" , "Alan Somers" , "Jan Sucan" , 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 Date: Mon, 26 Aug 2019 08:59:45 +0000 X-Mailer: MailMate (2.0BETAr6137) Message-ID: <4D99F70B-5BFD-447A-B833-D4F73CEECFF2@lists.zabbadoz.net> In-Reply-To: References: <201908231522.x7NFMLuJ068037@repo.freebsd.org> <20190826.042056.1329861772202588895.hrs@allbsd.org> <20190826.050922.1810654532466043358.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 46H5nV5BbWz47Px X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [-4.35 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[zabbadoz.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.94)[-0.937,0]; RCPT_COUNT_SEVEN(0.00)[7]; IP_SCORE(-1.11)[ipnet: 195.201.0.0/16(-3.75), asn: 24940(-1.79), country: DE(-0.01)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 09:10:23 -0000 On 25 Aug 2019, at 20:26, 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 >> 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 >> 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? No. I have systems without ping as I have systems without any INET support. We do use ping(though not ping6 yet imho) in startup scripts so we consider it essential to the base system. If you migrate ping6 into ping the first thing I’ll want to be able is to compile one or the other address family out and that’ll basically give me the same we have today + a name change I have to deal with unless argv[0] tricks and a hardlink are done. (Hint: if you make the compile out happen, deal with the fact that ping and ping6 can be there without the hardlink to the other — a bit of Makefile glue — and migrate it all in based on argv[0], I think I can be happy). In other notes (and I keep saying that), I can see a world when ping doesn’t exist anymore as IPv4 doesn’t exist anymore (I partially already live in that world). The fact that people still do not prepare themselves for this time is a bit strange to me as by the time FreeBSD 14 is still in support this IPv6-only world might very well happen for a majority of people. And FreeBSD 14-CURRENT really is only a year away now. So breaking what’s been good for almost 20 years now for a few more years doesn’t really seem to be worth to me. Just my 2cts, Bjoern