> 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?
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
