Moving lspci and setpci from /sbin to /usr/sbin?

[Jonathan Underwood]

On 29 January 2010 14:16, Maxim Burgerhout <maxim at wzzrd.com> wrote:
>> What if we link the lspci and lsusb as static binaries? That would allow
>> us not to break the filesystem architecture and have usable tools.
>
> You'd still miss pci.ids without /usr, so that would have to move too.
> Only place remotely suitable for that - not being beneath /usr or /var
> - would be /etc, but that's breaking with yet another long tradition
> of having pci.ids in /usr/share/hwdata.
>
> I see two camps: people who want to move lspci to /usr/(s)bin and
> people who want libpci to move to /lib(64). Both options create a more
> consistent environment. And moving libpci to /lib(64) has the benefit
> of making lspci half-functional if /usr is broken (pci.ids are still
> in /usr/share/hwdata), while moving lspci to /usr/(s)bin puts it in
> the same prefix as libpci.
>
> Personally, I think if some people need to have lspci working without
> /usr, then that should probably weigh heavier than lspci having the
> same prefix as libpci.
>
>
>>> Or differently: Everything in /bin and /sbin, must only be
>>> dynamically linked against libraries in /lib|/lib64. The fact lspci
>>> is linked against /usr/{lib|lib64}/libpci.so.X is a defect.
>>>
>> I agree.
>
> That sounds pretty logical, indeed. But I think it might be a long
> road to get there. I did a quick check for binaries in /sbin and /bin
> that are directly linked to libs in /usr. There's a good lot more: my
> F12 system gives these binaries in /sbin:
> - umount-devkit
> - rpcbind
> - iw
> - nash
> - iptables-multi
> - rpc.statd
> - lspci
> - plymouthd
> - sulogin
> - mount.nfs
> - dhcp6c
> - crda
> - unix_update
> - setpci
> - umount.hal
> - ip6tables-multi
> - unix_chkpwd
> - mkfs.ntfs
>
> An these in /bin:
> - rpm
> - mailx
> - login


This all seems very subjective. Different people will have different
thoughts on what is "essential" for recovery in the situation where
/usr can't be mounted. Many of these arguments are moot anyway,
because nowadays if as system gets hosed to the extent that /usr can't
be mounted, the most effective way to recover is to boot the machine
in question with a live CD or USB and have the full range of tools
accesible to diagnose the problem.