On August 10, 2010 04:18:10 am Stanislav Maslovski wrote: > On Tue, Aug 10, 2010 at 03:15:35AM -0600, Bruce Sass wrote: > > /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). > > Not just to repair. First of all, / must have enough tools to > bring the system up to the point where the other file systems can be > mounted (i.g., over the network).
Ya, I consider that to be the main use for the `core set of tools that can be counted on'. > > 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)? > > All files that a tool requires to operate must be there, for sure. > > > 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? > > Can you give examples of such special cases? Nope, it just seemed short-sighted to ignore the possibility. Simon McVittie mentioned an even better/plausible situation where some crippling wouldn't really matter... > (For instance, if /bin/vi is vim, it's OK if it can't do syntax > highlighting until /usr is mounted, as long as it can edit text.) > > 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. > > This is an unfortunate consequence of the fact that less and less > developers separate /, /usr, /var, etc. partitions on their machines. > In the past I always did it on my workstations, however, stopped > doing it around the time of lenny's release. Hehe... never run into a process that starts filling up the HDD, or perhaps had to use an HDD small enough that the possibility even existed. <shrug> > > 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. > > Well, just the other day I was helping a user on #debian to repare > his Debian installation, using mostly sed to edit the config files. > Nano was not functional without /usr and it seemed he did not have > any other editor. Hmm, /bin/nano worked for me. It spit out a screen full of warnings about stuff from /usr it couldn't find, then asked if it should continue. I don't know what it was missing but it worked well enough to edit /etc/network/interfaces. Thanks. - 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/201008100632.03036.bms...@shaw.ca
