On Wed, May 13, 2015 at 01:10:05PM -0700, J.C. Cleaver wrote: > On Tue, May 12, 2015 1:41 am, Richard W.M. Jones wrote: > > On Tue, May 12, 2015 at 10:34:28AM +0200, Nikos Mavrogiannopoulos wrote: > >> On Tue, 2015-05-12 at 09:04 +0100, Richard W.M. Jones wrote: > >> > > While working for an updated ipcalc to support ipv6 transparently, I > >> > > figured we have more tools which are not IPv6-ready and awkwardly > >> > > provide an additional tool with a -6 suffix, supposedly for separate > >> > > IPv6 support. That looks like a relic of the past, we still drag. > >> IPv6 > >> > > support should be transparent in programs (fortunately we don't have > >> > > ssh6). Any objection to fill bugs to merge the following tools with > >> > > their ipv4 equivalent? > >> > > > >> > > ping6, geoiplookup6, tracepath6, traceroute6 > >> > > >> > While I agree with your assessment of the separate tools, I think > >> > you're better off filing bugs with the upstream projects. > >> > >> I'm interested in what fedora ships rather than the upstream project per > >> se. > > > > Fedora ships whatever upstream ships. Big changes like integrating > > separate programs together should be made upstream. > > > > https://fedoraproject.org/wiki/Staying_close_to_upstream_projects > > > >> The fedora maintainer may chose to switch to another upstream > >> project if that is required. > > > > Are there other such projects that have all the features of current > > ping/traceroute/etc but integrate the tools together? > > > > Rich. > > > > > Probably worth it to add fping/fping6 to the list as well: > https://github.com/schweikert/fping As Fedora fping maintainer, I can't do anything with this. It needs to be filed upstream. I see a few reasons why network testing tools like ping, traceroute, fping, etc. may still be using separate binaries for IPv6. One is that when you are testing network functionality, you often want to test IPv4 or IPv6 specifically. These tools aren't really end-user applications like ssh, where you don't care what protocol it uses to connect because the protocol is just a means to an end. With the network testing tools, you often DO care. Two is that the network testing tools often need to do protocol-specific low-level things, like open raw sockets or build packets manually rather than relying on the OS TCP/IP stack to do it. Three is that these tools were often ported from IPv4 and don't support integrated functionality (due to #2). They can be compiled for either IPv4 or IPv6, but not both at the same time. For example, the fping RPM used to build the software twice--once for IPv4 and once for IPv6--and then package up the results together. This changed with newer fping versions, however. I don't think pushing Fedora maintainers on this by filing bugs downstream is going to change things. It is the upstream software that needs enhancement, so the bugs should be filed upstream. Also, suggesting alternate upstream projects that have the integrated IPv4/IPv6 functionality is fine, but they may not be drop-in replacements for the existing tools. In that case the existing tools should stay and the new ones can be added to the distro separately if desired. You can't exactly stop shipping a "ping" command and replace it with "gnip" just because the latter supports IPv4+IPv6 with a single command. Add it sure, but not replace. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
