I can help out if the package maintainers for these tools are either not interested or too busy to update them...

(In reply to Peter from comment #0)
> Usage: ifcfg DEV [[add|del [ADDR[/LEN]] [PEER] | stop]

> Expected results:
> Display list of all network devices - perhaps having this run 'ip addr show'
> if no arguments are supplied to ifcfg.

IMHO expected results are to show help, because DEV is mandatory, not optional.

> It's like the route and ip route command (iproute2 tools) that replaced it
> (a loooong time ago) ... why is route still there? Get rid of it or alias
> route to ip route by default, so people start getting the idea of using the
> new command sets, and update man to reflect that.

Plan (bug #687920, comment #1) was to remove net-tools (package with route & ifconfig) from default installation so lot of people would finally notice there's something else then route/ifconfig. We got there in some point but then people complained so it's been added (bug #868643, comment #5) back (which I'm not quite happy with).

Alias route to 'ip route' or ifconfig to 'ip addr' is not a solution as the syntax is totally different.

I guess you're right and showing the list of all interfaces when no arguments are supplied is the way to go.

However, I'd suggest using the 'ip' command directly as this is just a simple wrapper resembling ifconfig.

We've managed to drop vconfig and bridge-utils so far.  Hopefully people will forget about net-tools one day, too...

(In reply to Jiri Popelka from comment #2)
> (In reply to Peter from comment #0)
> > Usage: ifcfg DEV [[add|del [ADDR[/LEN]] [PEER] | stop]
> 
> > Expected results:
> > Display list of all network devices - perhaps having this run 'ip addr show'
> > if no arguments are supplied to ifcfg.
> 
> IMHO expected results are to show help, because DEV is mandatory, not
> optional.
> 
> > It's like the route and ip route command (iproute2 tools) that replaced it
> > (a loooong time ago) ... why is route still there? Get rid of it or alias
> > route to ip route by default, so people start getting the idea of using the
> > new command sets, and update man to reflect that.
> 
> Plan (bug #687920, comment #1) was to remove net-tools (package with route &
> ifconfig) from default installation so lot of people would finally notice
> there's something else then route/ifconfig. We got there in some point but
> then people complained so it's been added (bug #868643, comment #5) back
> (which I'm not quite happy with).
> 
> Alias route to 'ip route' or ifconfig to 'ip addr' is not a solution as the
> syntax is totally different.

Wow I didn't see those bugs - that's like 3 years ago now, and then a year after you removed it you added it back in?

I couldn't see exactly the time frame from those two bugs, but that's the general idea I get from reading through them... and in the first bug you mentioned, comment 6 with the reply from Martín Ferrari, is quite interesting, and that takes us back to 2007. 

So 7 years later and we're still being confused about what we should and shouldn't be using.

The reason I raised this bug as an issue is because I kept seeing deprecated through the man pages for various net-tools apps, yet seeing forums, blogs, wiki's, 3rd party apps etc all pointing at net-tools to setup routes, interfaces, diagnose connectivity issues etc.

'route add ...', 'netstat -l' or 'ifconfig ... ' etc instead of 'ip route add', 'ss -l' or 'ip addr', and so on.

The clear message I'm getting out there is use net-tools apps, not the iproute2 apps... 

It's almost like no one knows about the iproute2 tools at all, and I agree with you writing wrappers to point to iproute2 tools, so they look and feel similar to net-tools apps, is not the way to go. Not just from the syntax point of view but from the obvious confusion they are causing, it's not helping to get iproute2 tools established and moving people away from net-tools.

My only gripe with the iproute2 tools is the formatting of the output, and the vagueness of the man pages. They are faster, more advanced, and sophisticated than their net-tools counterparts, but they look ugly, and less polished, and the man pages are really detailed, yet completely unhelpful... quite possibly this could also be impacting peoples adoption of iproute2 over net-tools.

By way of example:

netstat -lep vs ss -lep
http://pastebin.com/UDiHxKPh

You can see from this post ss is really ugly, when shown on screen it takes up the entire width of the terminal, so it looks ugly onscreen as well, but that paste shows you what it looks like in a small terminal window. It's almost unreadale, being spread out of 3 or 4 lines. Whereas netstat is formatted in a much nicer way, so on a fullscreen terminal it doesn't look ugly and handles much nice on a small terminal window than ss does. Also ss doesn't group active services, and doesn't mention udp, of course it shows the udp sockets, but it doesn't mention 'udp' anywhere in the output.

The output from netstat and again I say purely by way of example, is much more intuitive, - easier to read, locate information, and understand what's happening, where and by whom. 

This is true of a lot of the other tools as well. The output is just nicer in net-tools than the iproute2 equivalents.

The man pages for 'ip route add' vs 'route add':
http://pastebin.com/akEeX6Z1

You can see clearly here, route add give's many examples, the info is formatted in a much easier to understand way, the synopsis is clear, the options are clear and easy to follow, but with ip route add it's like magic if you manage to get a working syntax to add anything beyond the SINGLE example they give you.


Are these two gripes something the creators of iproute2 can address perhaps? Because I really think that would help with adoption more than worrying about whether there is a wrapper in place...

I think you took the right approach though in removing net-tools, and you should have stuck with that, giving people the option to install net-tools IF they really wanted to use those instead of the iproute2 apps, perhaps with a warning that the net-tools package would no longer be developed/packaged, and phased out completely by the following release?

Fedora 19 to Fedora 20 had a few big steps that jolted me a little, pulling out iptables and ip6tables services (to name but one), and going straight up with the fairewalld service. I had to look up what happened to them, wondering if I'd lost something and ensuring that the world was still safe and things were working the way they should etc... but I got over it in about 5 minutes and moved on.

Back to the wrappers - you could create a separate package for those, ie iproute2-scripts for example, that include net-tools 'like' wrappers for their iproute2 counterparts, if people REEEEALLY need them... but then again why bother, if the man pages are cleaned up for the iproute tools and the formatting is cleaned up and made more presentable, then people will ease into them with much more grace and ease of acceptance... 

This is just my 2cents worth :)

When I say a lot of the other tools it's those 2 that are the main offenders

The man pages of the ip route command

and the output from ss

The other tools man pages and output are on par with net-tools

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Hi Peter,

feel like recovering the discussion about net-tools versus iproute? On bugzilla or off bugzilla.

Pavel

When available for new discussion or with new information, please either reopen this umbrella bug or start individual bug reports for individual issues.