Re: No to StowFS!

[Alfred M. Szmidt]

   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!