as ip can also be used by regular users, it would make sense to make it availble to them also. debian seems to install ip in /bin and installing a symlink from /sbin/ip to /bin/ip - which would work for me. thanks
the same argument can be made for ifconfig, so why havent people bothered with that too ?
if that increases the chances of making ip available, then i am all for making ifconfig available too. in the end however, i only care about ip. also, in debian only ip is available to the user by default.
ifconfig is available in /bin on Fedora, and I'm sure I already asked you about it, Mike...
unless there's a bug about it, i see no record of the question being posted previously wrt ifconfig simple enough to send a git patch for iproute2 upstream. i wouldnt bother with a symlink as anything hardcoding a full path is broken anyways. i'll include the change in the next version bump.
moved it in 2.6.35. guess we'll find out what packages have the path hardcoded and need to be fixed ;).
I'm not really sure about this, but it seems to break my network config somehow. There also are several hardcoded paths in /etc/init.d/network which may be the issue here.
i must have grepped wrong, but i thought i checked openrc and didnt see any hits. i'll revert the change for now.
whats so bad about a symlink? in any direction?
You forgot to revert the change and that broke a few things. I added a -r1 that installs in /sbin but symlinks to /bin, and should solve all trouble.
i'm not doing symlinks. packages need fixing first.
What the problem is with symlinks at all? flame@yamato ~ % ls -l {/usr,}/{s,}bin | egrep -e '-> (../..)?/s?bin' lrwxrwxrwx 1 root root 14 20 lug 17.09 pidof -> /sbin/killall5 lrwxrwxrwx 1 root root 8 25 apr 19.04 rc-status -> /sbin/rc lrwxrwxrwx 1 root root 14 15 lug 09.41 fsck.hfs -> /sbin/fsck_hfs lrwxrwxrwx 1 root root 14 15 lug 09.41 fsck.hfsplus -> /sbin/fsck_hfs lrwxrwxrwx 1 root root 14 25 apr 19.08 fsck.jfs -> /sbin/jfs_fsck lrwxrwxrwx 1 root root 7 25 apr 17.47 mdev -> /bin/bb lrwxrwxrwx 1 root root 15 15 lug 09.41 mkfs.hfs -> /sbin/newfs_hfs lrwxrwxrwx 1 root root 15 15 lug 09.41 mkfs.hfsplus -> /sbin/newfs_hfs lrwxrwxrwx 1 root root 14 25 apr 19.08 mkfs.jfs -> /sbin/jfs_mkfs lrwxrwxrwx 1 root root 15 20 lug 18.16 mount.lowntfs-3g -> /bin/lowntfs-3g lrwxrwxrwx 1 root root 12 20 lug 18.16 mount.ntfs-3g -> /bin/ntfs-3g lrwxrwxrwx 1 root root 13 20 lug 18.07 basename -> /bin/basename lrwxrwxrwx 1 root root 11 20 lug 18.07 chroot -> /bin/chroot lrwxrwxrwx 1 root root 8 20 lug 18.07 cut -> /bin/cut lrwxrwxrwx 1 root root 8 20 lug 18.07 dir -> /bin/dir lrwxrwxrwx 1 root root 12 20 lug 18.07 dirname -> /bin/dirname lrwxrwxrwx 1 root root 7 20 lug 18.07 du -> /bin/du lrwxrwxrwx 1 root root 8 20 lug 18.07 env -> /bin/env lrwxrwxrwx 1 root root 9 20 lug 18.07 expr -> /bin/expr lrwxrwxrwx 1 root root 9 20 mag 22.13 gawk -> /bin/gawk lrwxrwxrwx 1 root root 9 20 lug 18.07 head -> /bin/head lrwxrwxrwx 1 root root 20 9 ago 19.08 iptables-xml -> /sbin/iptables-multi lrwxrwxrwx 1 root root 11 20 lug 18.07 mkfifo -> /bin/mkfifo lrwxrwxrwx 1 root root 11 20 lug 18.07 mktemp -> /bin/mktemp lrwxrwxrwx 1 root root 11 23 lug 15.39 passwd -> /bin/passwd lrwxrwxrwx 1 root root 13 20 lug 18.07 readlink -> /bin/readlink lrwxrwxrwx 1 root root 8 20 lug 18.07 seq -> /bin/seq lrwxrwxrwx 1 root root 10 20 lug 18.07 sleep -> /bin/sleep lrwxrwxrwx 1 root root 9 20 lug 18.07 sort -> /bin/sort lrwxrwxrwx 1 root root 9 20 lug 18.07 tail -> /bin/tail lrwxrwxrwx 1 root root 10 20 lug 18.07 touch -> /bin/touch lrwxrwxrwx 1 root root 7 20 lug 18.07 tr -> /bin/tr lrwxrwxrwx 1 root root 8 20 lug 18.07 tty -> /bin/tty lrwxrwxrwx 1 root root 10 20 lug 18.07 uname -> /bin/uname lrwxrwxrwx 1 root root 9 20 lug 18.07 vdir -> /bin/vdir lrwxrwxrwx 1 root root 7 20 lug 18.07 wc -> /bin/wc lrwxrwxrwx 1 root root 8 20 lug 18.07 yes -> /bin/yes If you're just going to go the long route because you don't like symlinks for taste, we've got an even worse problem here.
(In reply to comment #10) > i'm not doing symlinks. come on - you can do better than that. > packages need fixing first. ok. so we have /etc/init.d/network that needs a trivial patch. what else have folks encountered?
some of those symlinks are invalid (different argv[0]) while the rest of them probably should die. existing crap is not a valid excuse to add more crap.
@spanKY: you broke vzctl and god only knows how many other pkgs.
old news, and your tree is old. dont report bugs against old things.
http://sources.gentoo.org/baselayout/branches/baselayout-1_12/net-scripts/net/iproute2.sh?r1=3174&r2=3175
Install ss into bin also please.
umm, no. mount /usr if you want ss.
should be all set now in the tree; thanks for the report! Commit message: Move ip into /bin http://sources.gentoo.org/sys-apps/iproute2/iproute2-3.5.0-r1.ebuild?rev=1.1
Thanks for randomly breaking stuff. Please add a symlink so that /sbin/ip still exists and you don't randomly break existing scripts that hardcoded that path.
*** Bug 432014 has been marked as a duplicate of this bug. ***
this ignorant behaviour is just inacceptable. please add a compatibility symlink.
To everyone complaining about legasy symlinks, why not file bugs against the packages that hard code "/sbin/ip" as the path so they can be fixed?
(In reply to comment #23) > To everyone complaining about legasy symlinks, why not file bugs against > the packages that hard code "/sbin/ip" as the path so they can be fixed? sure, this has to be done. but simply breaking things for no reason is not acceptable. this reminds me of the ruby community who has no sense whatsoever for providing backwards compatibility in lots of core packages. this is just sad.
@hollow: If we set up a compatibility symlink, that may allow backward compatibility, but how do we know then which packages need to be fixed? We don't because the symlink hides the issue. Also, I want to raise another issue on this bug that I will wait for the maintainer to respond to. We now move the ip and arpd binaries in our ebuild to places different from where upstream installs them. Why do we do this in the ebuild instead of sending patches upstream to move them?
(In reply to comment #20) take your snark elsewhere by actually fixing the broken packages (In reply to comment #22) this crap doesn't belong here (In reply to comment #25) yes, sending patches upstream is the next step
Unfortunate attitude to each other. before making such proposal and then pouring the scorn to developers, followng have to be made first: 1. Rationale in moving ip and arpd to /bin (in contrary with upstream). oh c'mon Fedora has ip in /bin! , let's follow, good grief.
(In reply to comment #3) > ifconfig is available in /bin on Fedora, and I'm sure I already asked you > about it, Mike... [root@redbull ~]# which ifconfig /usr/sbin/ifconfig [root@redbull ~]# which ip /usr/sbin/ip From my Fedora machine. I realize comment #3 is old but I figured it's worth mentioning. From my RHEL6 machine the utilities are in /sbin/ and from my RHEL7 machine they're in /usr/sbin/.
(In reply to comment #28) they haven't updated to latest net-tools yet then :). i pushed a commit there to move ifconfig into /bin by default.
*** Bug 467830 has been marked as a duplicate of this bug. ***
https://bugs.gentoo.org/show_bug.cgi?id=467830 is not a duplicate of this bug, but a ticket tracking a regression of this bug. It is just rude to just move location like that without notifying the packages that rely on the old location. It is wrong to just break people's systems and prevent Gentoo being used for mission-critical applications. There should be a temporary backwards compatibility symlink, and all the packages using the old location should be notified of the change and given time to point to the new location before the temporary symlink is removed.
No offence, but recent sys-cluster/torque (5.1.0) has hardcoded /sbin/ip like: (cluster) Tethys torque-5.1.0-1_4048f77c # find . -type f -exec grep "/sbin/ip" '{}' \; FILE *pPipe = popen("/sbin/ip addr","r"); FILE *pPipe = popen("/sbin/ip addr","r"); (cluster) Tethys torque-5.1.0-1_4048f77c # I know it's upstream's fault and I may contact them. But a symlink would do no harm (5 years after, and people think ip is still in sbin). Just reporting here for reference.
(In reply to Panagiotis Christopoulos from comment #32) this bug is closed. if a diff package is broken, then you should file a new bug for that package and contact upstream.
the ArrayVPN client (http://client.arraynetworks.com.cn:8080/en/troubleshooting) uses /sbin/ip to configure its tunnel, and does not report errors while /sbin/ip is not found. It's hard for a regular user to find the error because Gentoo is not in the support list. So why not make situations like this better by making a backwards compatibility symlink.
