Re: [gobolinux-devel] Fedora to change the filesystem hierarchy.

Further to Lucas C. Villa Real email: 
http://lists.gobolinux.org//pipermail/gobolinux-devel/2011-November/004318.html 
"[gobolinux-devel] Fedora to change the filesystem hierarchy", I just 
came across a recent interesting discussion: 
http://www.osnews.com/comments/25556 "Understanding the /bin, /sbin, 
/usr/bin, /usr/sbin Split".

A comment by Alfman: http://www.osnews.com/thread?505332 "Re: Filesystem 
Hierarchy Standard" caught my attention. I quote:

""You might think Gobo Linux brings order, but you aren't taking into 
account that it carries the 'legacy' structure too, it just hides it."

Of course you are correct, but solving that is a real conundrum. 
Unfortunately one is required to maintain legacy paths whenever 
compatibility is required since the old paths are hard coded in binaries 
and libraries throughout the linux software codebase. The *inability* to 
change them makes the status quo ideologically imperfect, even those who 
don't mind the legacy paths should recognize this.


In my personal distro, I've given it some thought and came up with two 
possible compatibility solutions. Keep in mind, a motivating goal is to 
keep application specific files together so that, as with GoboLinux, 
applications can be installed by untarring a single directory. A list of 
commands can be built using symlinks pointing to their applicaiton 
directories.


Solution A. Remove the dependency upon legacy paths by modifying the 
kernel and/or libc to treat file requests as "named resources" instead 
of absolute file system paths. This mapping could be stored in either a 
system wide or application specific named resource map. This way, when 
an application requests "/etc/resolv.conf" or "/usr/bin/perl" or 
"/dev/ttyS0", it could be mapped to the actual file where-ever it is 
located. The mapping could be optional and revert to previous behavior 
as needed.

This would provide two immediate benefits:
1. The dependency on fixed legacy fs paths is eliminated (or rather it's 
internalized to the binaries/libraries).

2. It could provide excellent documentation about what the external 
dependencies are for any given application, and makes it trivial for 
administrators to change them per application without recompiling a thing.


Solution B. Run applications inside an automatic CHROOT environment to 
mimic the environment they expect.
Basically, the chroot contains a fake root directory layout which 
symlinks to the actual directory layout and can do so without polluting 
the actual directory layout with legacy paths.

chroot/hostfs -- mount --move of /
chroot/bin/ -> hostfs/app/bin
chroot/sbin/ -> hostfs/app/bin
chroot/usr/bin/ -> hostfs/app/bin
chroot/etc/ -> hostfs/config


The problem with solution B, is that while it works in a compatible way, 
users of these apps will see the legacy paths instead of the hostfs paths."

I just thought the above information might be of use to the GoboLinux 
developers.