NonStandard Directory Tree, Wildcards in PATH, etc

Andrew Calkin calkin at ieee.org
Tue Aug 10 16:08:31 PDT 2004


On Tue, Aug 10, 2004 at 07:31:13PM +0100, Jeremy Henty wrote:
> 
> Ian Molton wrote:
> 
> > Jeremy Henty <jeremy at chaos.org.uk> wrote:
> > 
> > > [snip,jch]
> > > Joking aside, putting the OS in a non-root directory is a good
> > > idea.  Windows got this right.
> > 
> > Could you expound on that a bit?
> 
> Blimey, you expect me to justify my bullshit??!!??  :-) Mostly it's my
> love of tidyness and uniformity: I like things to be modular and for
> directories to contain a module, the whole of that module and nothing
> but that module.  "/" on Unix systems contains several directories
> that are part of the core OS ("/usr", "/dev" etc.) and several others
> that are not ("/mnt", "/home", "/opt" etc.).  Yuk!
> 
> *But* ... now wouldn't it be cool to have several versions of the OS
> in directories called "/linux-<version>", a symlink /linux ->
> linux-<version-current> and be able to change versions by pointing
> that symlink elsewhere and rebooting.  Is this feasible?  Not when
> booting with lilo, but might grub be able to do it?
> 
Hi, just a question, but why are you so keen on the idea of the above
being in directories? I think the above scenario is _very_ common
amongst the LFS community, but if instead of different versions of the
OS in different directories, they have different versions on different
partitions. And yes, lilo can handle this. And yes, this concept is one
of the fundamental precepts of the (standard) LFS build process, hence
my earlier comment about the LFS community. I cannot see how having some
other arbitrary directory structure could possibly make maintenance of a
system any easier than with some existing package manager (or a custom
package manager, as some here have devised, that better suits their
needs). Certainly drastically changing the convention that most package
configure->make->make install routines make use of, with respect to
location of destination files, could only bring additional headaches.

I personally find the layout of files to be quite logical under *nix and
*BSD based systems, after being initially confounded when migrating from
a Windows-based existence some years ago. But now I see the value in
having executable files all located under a search path, instead of the
"where would you like this icon to be located" debacle that I face when
I am forced to return to windows. Note that on my personal bias, I work
almost entirely from the CLI when invoking programs; the only buttons on
my desktop are for an aterm window, for quitting X, and for mozilla.

Regards,
//Andrew



More information about the lfs-chat mailing list