# repoquery --qf "%{sourcerpm}" --disablerepo='*' --enablerepo=rawhide --whatrequires net-tools | sort | uniq bontmia bwm-ng dracut egd firehol globus-common initscripts libguestfs netdump-server nmbscan ocfs2-tools ocsinventory-agent olpc-netutils openvpn openwsman rkhunter smokeping wicd wifi-radar wlassistant net-tools is deprecated since time ago. iproute is the way to go.
Yes, the plan is to get net-tools (at least) out of the default installation. We probably never get rid of it, because I think there will always be many people using it. The first step is to remove (bug #65114) initscript's dependency on net-tools, because that's the package that pulls net-tools into default installation. When this happens and net-tools won't be installed by default people that will be still relying on it will be discovering that there's something like iproute.
> The first step is to remove (bug #65114) initscript's dependency on net-tools, > because that's the package that pulls net-tools into default installation. dracut libguestfs netdump-server ocfs2-tools olpc-netutils ... also are basic for the system.
(In reply to comment #2) > dracut libguestfs netdump-server ocfs2-tools olpc-netutils ... also are basic > for the system. I used --repoid=fedora-source instead of --qf "%{sourcerpm}" and it generates slightly different list of packages where's dracut-network instead of dracut. dracut.spec confirms that only dracut-network sub-package requires net-tools. From the list that the repoquery generates only initscripts are installed on my system.
(In reply to comment #3) > I used --repoid=fedora-source instead of --qf "%{sourcerpm}" and it generates > slightly different list of packages where's dracut-network instead of dracut. > dracut.spec confirms that only dracut-network sub-package requires net-tools. > From the list that the repoquery generates only initscripts are installed on my > system. You must query 'sourcerpm' from 'rawhide' in openvpn.spec : # For ifconfig and route. Requires: net-tools in ocfs2-tools.spec: Requires: bash, coreutils, net-tools, modutils and so on ...
Maybe a wrapper for ip, ss, arp, ... should be created to emulate ifconfig, route, netstat, ...
net-tools future ================ -------- Original Message -------- Subject: net-tools future Date: Sun, 15 Mar 2009 17:30:18 From: Martín Ferrari <tincho> To: debian-devel@@lists.debian.org Hi, Luk Claes and me, as the current maintainers of net-tools, we've been thinking about it's future. Net-tools has been a core part of Debian and any other linux based distro for many years, but it's showing its age. It doesnt support many of the modern features of the linux kernel, the interface is far from optimal and difficult to use in automatisation, and also, it hasn't got much love in the last years. On the other side, the iproute suite, introduced around the 2.2 kernel line, has both a much better and consistent interface, is more powerful, and is almost ten years old, so nobody would say it's untested. Hence, our plans are to replace net-tools completely with iproute, maybe leading the route for other distributions to follow. Of course, most people and tools use and remember the venerable old interface, so the first step would be to write wrappers, trying to be compatible with net-tools. At the same time, we believe that most packages using net-tools should be patched to use iproute instead, while others can continue using the wrappers for some time. The ifupdown package is obviously the first candidate, but it seems that a version using iproute has been available in experimental since 2007. So, the roadmap would be: - Send patches to net-tools using packages to use iproute instead - Development of the wrapper scripts - Uploading to experimental a net-tools-compat package, to allow wider testing. - Upload to unstable About the wrapper scripts: * ipconfig, route: the most difficult ones, both can be replaced by calls to "ip", maybe except for some obscure options. * netstat : sstat provides almost the same information, just some formatting changes and parsing the command line * rarp should be dropped, as the linux kernel doesn't support it anymore, since the 2.3 series. The replacement, arpd, is already included in iproute. * ipmaddr works exactly as "ip maddr", in fact, the code is from the iproute sources. Same for iptunnel and "ip tunnel". In both cases, they're just replaced by a symlinkm, as the ip command recognises that. * nameif: can be replaced by "ip link", not sure if it's worth the effort (does anybody actually use it?) Problematic tools: * mii-tool: it could be dropped and replaced by a pointer to ethtool as it's not meant to be used automatically by scripts. On the other hand, it's distributed as a stand-alone tool [0] and we could do the same. * plipsetup, slattach: we don't know of any replacement for those, but could be distributed separately too. Also, it's dubious if anyone still uses them. 0: http://freshmeat.net/projects/mii-tool/ -- Martín Ferrari <tincho> -- To UNSUBSCRIBE, email to debian-devel-REQUEST.org with a subject of "unsubscribe". Trouble? Contact listmaster.org ---end---
thread http://lists.debian.org/debian-devel/2009/03/thrd2.html#00780
(In reply to comment #4) > in openvpn.spec : > # For ifconfig and route. > Requires: net-tools > > in ocfs2-tools.spec: > Requires: bash, coreutils, net-tools, modutils > > and so on ... Yes, but these are not (at least on my machine) installed by default. Priority is initscripts, bacause from the list only initscripts is installed by default. (In reply to comment #5) > Maybe a wrapper for ip, ss, arp, ... should be created to emulate ifconfig, > route, netstat, ... This is a comment from the previous net-tools maintainer I found in one (private) RHEL bug, where the wrapper for 'ip' to emulate ifconfig was also discussed: "we've already tried that but the command line options of both commands differ significantly. In fedora most of the scripts (initscripts/networking) has been using iproute commands now and we're trying to teach customers to switch to ip as well. (iproute has active upstream following kernel changes closely, immediately bringing features kernel adds into iproute releases). Wrapper is one option, but that would have to be properly staffed. We're talking not only about ifconfig but as well about netstat and other tools net-tools package is providing. All of them have their equivalents in other packages, but unfortunately we still have customers relying on net-tools."
(In reply to comment #1) > the plan is to get net-tools (at least) out of the default installation This should be reality since fixing of bug #785794.
According to bug #868643, comment #5 net-tools has been added to the 'standard' group so it will (>=F18) still be in most non-minimal installs.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.