# /sbin/ip or /bin/ip, a warning about iproute2

## jamapii

Hi,

iproute2-3.8.0 installs its binaries in /bin, no longer /sbin. This will break openvpn-2.3.1 (at least for me), which isn't in portage, but who knows what else it will break (vtun? your scripts?).

See also

https://forums.gentoo.org/viewtopic-p-7191632-highlight-.html#7191632

My script to prevent breakage becomes:

```
#!/bin/sh

grep -E "^obj /s?bin/" /var/db/pkg/*-*/{net-tools,iproute2}-*/* | cut -d" " -f2 |

  while read file; do

    prog=$(basename $file)

    bin=/bin/$prog

    sbin=/sbin/$prog

    [ -e $bin -a -e $sbin ] && continue

    if [ $file = $bin ]; then

      file2=$sbin

    else

      file2=$bin

    fi

    echo ln -s $file $file2

  done 
```

(this creates symlinks in /sbin and /bin, whatever doesn't exist.)

If you run this script and later update net-tools or iproute2, it may complain about collisions. In this case, you can do 

```
FEATURES="-collision-protect" emerge -1 iproute2 # or whatever
```

 to force the update.

----------

## khayyam

jamapii ...

I'm not sure the script is such a good idea, having stray (non-package installed) links in /bin, /sbin, etc, should be avoided. The problem will get resolved (iproute2-3.8.0 is ~arch), and as I understand it packages, specifically openvpn, find the location of ip/ifconfig at buildtime, so linking will just perpetuate the issue. This was the case with the ifconfig relocation (which I assume is the link you provided), and a re-emerge of openvpn was enough to resolve the problem.

best ... khay

----------

## kurly

 *khayyam wrote:*   

> The problem will get resolved (iproute2-3.8.0 is ~arch)

 

The rest of your point is valid, but I should point out that iproute2-3.8.0 is currently stable on alpha, amd64, arm, hppa, ia64, m68k, ppc, ppc64, sparc, and x86.  It remains ~arch on mips, s390, and sh.

This is part of why I've given up on stable and track ~arch.  The shield that protects stable users from unexpected change is weakening.  Since ~arch itself is very usable nowadays, I see fewer reasons to use stable, unfortunately.

Obviously tracking ~arch doesn't help in this situation, but tracking stable doesn't either... *shrug*

----------

## Ant P.

Did stable get a huge version bump recently? I've had it in /bin/ip for years now (and vastly prefer that to having to prefix all my commands with /sbin/ or su -c).

----------

## khayyam

 *kurly wrote:*   

>  *khayyam wrote:*   The problem will get resolved (iproute2-3.8.0 is ~arch) 
> 
> The rest of your point is valid, but I should point out that iproute2-3.8.0 is currently stable on alpha, amd64, arm, hppa, ia64, m68k, ppc, ppc64, sparc, and x86.  It remains ~arch on mips, s390, and sh.

 

kurly ... haha, ok, thanks for pointing that out. My reason for thinking it was still ~arch was that I'd keyworded it only the other day to see if the previous version was the cause of my "RTNETLINK answers: Operation not supported" error, so that was still fresh in my mind (yes, all the necessary NETLINK options bar NET_SCH_INGRESS, which seems to have disapeared, are enabled).

best ... khay

----------

## Anon-E-moose

I find it rather stupid to do something like change the directory where ip resides without taking into account the different packages that expect it to be in /sbin, on the order of udev type stupid. 

Yes, I recompiled openvpn and it works ok. But deluge doesn't (recompiling didn't help) so I assume that the fault is somewhere in a python module. I just didn't feel like spending time chasing it down this morning. So I put in a temp link to /sbin just to get it working.

Are there no developers who can think further than "I'll change this simply because I can"

[/rant]

----------

