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

[Maxim Burgerhout]

> 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

It goes a bit further than this, even. A quick check in /lib shows
that at least libcrypt is linked against another library in /usr/lib.

Maybe this should be checked out / decided on on a broader scale,
apart from the discussion on lspci?