I know that there are A LOT of scripts that will need to be CORRECTED.
Not as many as you think. Most scripts figure out where the interpeter is at compile/configure time. I do not think that keep a loop symlink of USR->/ is a good idea, since you will never be able to do a "find / -name *something*". So, we need to correct those scripts. (* There are scripts with references to /usr/python or /usr/local/perl) find / -P -name FOO I know that StowFS doesn't break POSIX, but my idea, as I know, also doesn't break it. I know that stowfs does part of what I want, but it still keeping / ugly. What I want is not only organized binaries packages, but also a clean and with no infinite loop /. But / doesn't have a infinite loop. This is quite a silly argument, don't you think? /usr is only for backwards compatiblity, it can be removed safetley if it is annoying (I always remove it) when you build a program to work on an directory, all that you will need from that package is the binary location. If this package is a library, you will need the /include, /usr/include, /usr/local/include to turn packages able to use your library. Why do you need /usr/include and /usr/local/include? So, if that is all that you need, you can do thing on a simpler way, without need to create unecessary directories on / (/bin, /sbin, /lib). /sbin might not be needed, true, but /lib, /bin and /include _are_ needed. It makes perfect sense to have a constant location where to find binaries, include files and libraries. Otherwise you will end up with really long compile lines since you will need to include many directories, and need to keep track of manually where packages are installed, something that should simply not matter. Also, searching through PATH is slow business, the more entries you have in PATH the longer it will take to search, ultimatley, PATH should be removed completely, or atleast left as a simple `PATH=/bin'. What you will need is, instead stowfs, that get package/bin and merge it on /bin, is a translator that gets package/bin and put it on PATH. The same is valid for /lib and /sbin (I know no variable to set "include" directories). You really don't want this. Really. The whole point of stowfs is to reduce the number of places where binaries/libraries/includes get searched in. I think that having a PATH that is _really_really_ long is very very ugly, and from what I can see, impossible to achive cleanly. You would have to modify programs to handle the case where PATH gets changed during a run. Consider the case where you have running programs which might need to have their PATH envvar updated. I do not know what are your problems with my idea. There are some Linux-based GNU systems that uses that directory organization. Sorry, but I know of no GNU/Linux systems that use this. All of them are built up around /place-with-executables, if that directory is called /bin, /Applications or /bin:/usr/bin:/usr/local/bin:/usr/foo/bin:... is not really an issue. I think your idea is flawed (or you need to put more thought in it to express why it is better), keeping PATH updated is tricky business, and it is also terribly slow to search through. Being required to list _all_ include directories or library directories is really a pain when you want to compile software. I.e. you cannot do something like `gcc -lbar -lbaz -lquux -L/lib -I/include -o foo foo.c', but you would end up with something like `gcc -lbar -lbaz -lquux -L/packages/lib/quux/ -L/packages/lib/bar -L/packages/lib/quux ....'. And what if you don't want to use /packages? As far as I can see, you wouldn't be able to change this place using scheme, right? I also fail to see what you mean by keeping / `pretty'. I think a / that looks like: /bin /lib /include /share /boot /packages /dev /tmp /var /home Is infact quite clean. Actually, if you consider the file system as the variable for search paths, then I think you will see how it is more powerful than having specific envvars for the purpose. Instead of specifying with PATH, INCLUDE_PATHS, LIBRARY_PATHS where to search things, you simply have programs search the content of /bin /include and /lib. And when you install, you just merge the content into those directories, and no need to worry about keeping any envvars updated across several running instances. Cheers, and happy hacking! _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
