Hello Matt! I was the person who closed the bug report (#414086) about iproute: become the new default. I did this because I see no value in it at all. I will try to elaborate on this further...
First of all, I have no evidence that any improvements in iproute itself is needed for it to become the new default. The only thing that's needed is that people start to actually use it. You can do this yourself just by installing it! (If you *do* find something that needs improvement in iproute, please file a bug about *that* and we'll fix it.) If you also want to completely get rid of net-tools, then I suggest you start filing wishlist bug-reports against the packages that depends on net-tools if they don't already have those. To find these packages you simply run "apt-cache rdepends net-tools". One of the main things you would want to get ported is probably ifupdown, and those who seek will find that in experimental there is a version who has been ported to use iproute instead of net-tools. There are several issues still remaining, not least keeping backwards compatability with the old syntax of /etc/network/interfaces. I've recently started to help out in improving this experimental version of ifupdown (see #456918 for my initial work) which is what I consider is the important part to get ported over (the rest of the packages can just pull in net-tools via it's dependencies, and hopefully they'll get ported over when enough people nag about why they must have both iproute and net-tools installed - where I'll just direct all those nags away from iproute). My goals is to have it included in time for Lenny, but I doubt that will happen so don't count on it! The remaining issues should be tracked as bugs against ifupdown though, not iproute! There are a couple of things that makes "just switching from net-tools to iproute" not that easy. First of all, iproute is a not portable to other platforms then Linux (since it uses "netlink" which is a kernel interface only available on Linux). Debian has non-linux architectures but none of them has ever been included in an official release AFAIK. I'll let you decide how important this is. Another thing is that iproute is not a superset of net-tools! When one thinks of net-tools you usually think of ifconfig and route. These two can and should be replaced by iproute commands, but there are several others: /usr/sbin/arp - no iproute equivalent AFAIK. /sbin/ifconfig - use ip link, ip addr, ... /sbin/nameif - use ip link set name foo dev bar or udev or whatever! /sbin/plipconfig - no idea. /sbin/rarp - no iproute equivalent AFAIK. /sbin/route - use ip route ... /sbin/slattach - no idea. /sbin/ipmaddr - probably can be replaced by iproute, no idea. /sbin/iptunnel - probably can be replaced by ip tunnel ... /sbin/mii-tool - use ethtool! /bin/netstat - why not keep using? (possible alternativ could be lsof) Basically, each transition needs to be looked into.... You can't just say "switch to iproute!". And no, none of these "missing" parts are things that are planned for iproute - we don't replace stuff just for the fun of it all. There's no need to write a new netstat for example (although I personally more often tend to use lsof then netstat). Who knows, but maybe the "useful" parts of net-tools should be split out so they can be pulled in separately but at the same time it seems silly to split up a small package like net-tools. One might also want to investigate what busybox offers, maybe the "missing parts" can be provided have good enough equivalents in busybox. But again, I want to stress that none of these are iproute problems. If you want have this bug as keeping track of when iproute can be "upgraded" to important (and thus "installed by default"), I suggest you start adding blocker bugs to this because I won't. If there's no activity on the bug, there's no reason to keep it around and I *will* close it again (and I hope I've given enough explanation about it this time). Personally I think a big transition issue like this where you need to collect alot of ideas and plan stuff are better done on a wiki or similar. Once you've figured out what needs to be done you file small individual bug-reports against affected packages, and each of those small bugs getting fixed will bring you closer to the grand unified goal. Hope this helps, have a nice day! -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
