/sbin and /usr/sbin, /lib and /usr/lib directories? AFAICT, the reason is so that a minimal but functional system is guaranteed to exist so long as a local HDD with a root filesystem is available (which doesn't necessarily include /usr); and that is a good thing to have because it gives developers a core set of software tools they can count on to always exist and facilitates troubleshooting or repairs if something breaks (e.g., bug# 592361, where I've worked around the problem by using /bin/nano to reconfigure the box with a static IP address).
If that is a good reason, perhaps even The reason, for having both /bin and /usr/bin, etc., then doesn't it follow that all files required by executables residing in /bin and /sbin should also be available so long as a local HDD with a root filesystem is available (otherwise those executables are either broken or crippled)? I suppose there could be cases where the broken or crippled functionality is not useful or required when a properly populated /usr doesn't exist, but I expect those would be "special" cases, because, generally, crippled or broken programs are a bad thing. ya? I'm trying to understand the logic behind it not being an automatic bug (i.e., something which is a good candidate to check for at build-time) for stuff in /bin and /sbin to require stuff in /usr; and I've gotten onto this because of bugs like #592361 and #589123, and the observation that over the last couple/few years I seem to be running up against problems related to this issue more and more frequently. With bugs in scripts (e.g., #589123) it should be good enough that a text editor is available, but with broken binaries (e.g., #592361) the potential to be put in a not-so-easy-to-fix situation is pretty high (remember, dpkg is not around when /usr is missing and the fix is going to arrive in a .deb)--so maybe that one should generate a warning of some sort. I was curious so... $ for f in /bin/* /sbin/*; do if [ "`file $f | grep ELF`" != "" ] ; then if [ "`ldd $f | grep /usr`" != "" ] ; then echo `dpkg -S $f`; ldd $f; fi; fi; done iputils-ping: /bin/ping6 linux-gate.so.1 => (0xb770d000) libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 (0x472dc000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0x4882b000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0x46bcc000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0x46d3d000) libz.so.1 => /usr/lib/libz.so.1 (0x46d5e000) /lib/ld-linux.so.2 (0x46bad000) isc-dhcp-client: /sbin/dhclient linux-gate.so.1 => (0xb770c000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0x4882b000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0x46bcc000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0x46d3d000) libz.so.1 => /usr/lib/libz.so.1 (0x46d5e000) /lib/ld-linux.so.2 (0x46bad000) discover: /sbin/discover linux-gate.so.1 => (0xb78f5000) libdiscover.so.2 => /usr/lib/libdiscover.so.2 (0x46d15000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x47109000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0x46bcc000) /lib/ld-linux.so.2 (0x46bad000) util-linux: /sbin/fsck.cramfs linux-gate.so.1 => (0xb7893000) libz.so.1 => /usr/lib/libz.so.1 (0x46d5e000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0x46bcc000) /lib/ld-linux.so.2 (0x46bad000) util-linux: /sbin/mkfs.cramfs linux-gate.so.1 => (0xb7755000) libz.so.1 => /usr/lib/libz.so.1 (0x46d5e000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0x46bcc000) /lib/ld-linux.so.2 (0x46bad000) iptables: /sbin/nfnl_osf linux-gate.so.1 => (0xb785f000) libnfnetlink.so.0 => /usr/lib/libnfnetlink.so.0 (0x46d15000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0x46bcc000) /lib/ld-linux.so.2 (0x46bad000) udisks: /sbin/umount.udisks linux-gate.so.1 => (0xb78ac000) libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0x4b1bb000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0x46d43000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x47277000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x47027000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0x46bcc000) libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x4b180000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x470f8000) librt.so.1 => /lib/i686/cmov/librt.so.1 (0x46eba000) /lib/ld-linux.so.2 (0x46bad000) libpcre.so.3 => /lib/libpcre.so.3 (0xb7856000) Are these bugs just waiting to bite, or frustrate troubleshooting efforts because some program is broken just when it is needed most? later, - Bruce -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008100315.36920.bms...@shaw.ca