Do we care about /sbin /bin linked to /usr/lib ?

[Chris Snook]

Steve Grubb wrote:
> Hi,
> 
> I wrote a utility that checks all apps in /bin & /sbin to see if they link 
> against anything in /usr. Is this a problem that we care about?
> 
> /bin/rpm uses something in /usr
> /sbin/arping uses something in /usr
> /sbin/audispd-zos-remote uses something in /usr
> /sbin/audisp-prelude uses something in /usr
> /sbin/audisp-remote uses something in /usr

I don't see why the above need to be in /bin or /sbin.

> /sbin/auditd uses something in /usr

This is a problem.  The sorts of people who care about auditd may want to rely 
on having a separate /usr partition to minimize the amount of code on their 
system that could possibly run before auditd is up and running.

> /sbin/cifs.upcall uses something in /usr

I don't think a lot of people are mounting /usr over cifs, but on principle, I 
don't think we should have filesystem-related things depending on /usr.

> /sbin/grubby uses something in /usr

I would think we really only need to be calling grubby when the system is fully 
booted.

> /sbin/lsusb uses something in /usr

This could be a problem for people booting off USB devices.  Mostly this is only 
used for liveCD/liveUSB, so we don't hit it, but with the rise of netbooks and 
such where people may want to boot off a USB-attached SD card, it could come up. 
  I don't think it's a high priority, but if there's an easy fix, we should do it.

> /sbin/nash uses something in /usr

That sounds bad.

> /sbin/setkey uses something in /usr
> /sbin/umount.hal uses something in /usr

Is HAL supposed to be involved with system partitions?  I was under the 
impression that it is not, so this doesn't need to be in /sbin.

-- Chris