Re: why are there /bin and /usr/bin...
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
Reply to: