Re: Hurd FS hierarchy (was Re: LD_LIBRARY_PATH troubles)

[Carl Wilhelm Soderstrom]

> All those are interesting questions, and we will have to work out the
> details.  How it could work is that /usr is still a real physical
> directory, and you attach a filesystem to it.  Then you install shadowfs
> on top of /, merging in /usr. Then all writes to /usr/.... would still
> go to the physical /usr.  Something like that.
        that setup makes the most sense to me.
        of course, I'm still puzzling a bit over why there is a need to move
all the /usr stuff to /. I know it cuts down the paths, but it adds more
complexity to /, which is something I'd like to avoid. :)

> However, note that all this is a work around specifically for Debian and
> other legacy stuff.  Eventually, we should do the right thing and put
> each package in its own directory, /package/foo/
> Then /bin would be the union of all /package/*/bin etc.

this gets back to the old per-package directory/per-function directory holy
war; but gives a reasonable answer to sort-of satisfy both parties. I think
QNX does something like this; but I don't remember clearly. 

one thing that just occured to me, would be to have a virtual filesystem
called 'packagefs' that you could browse; and under that, each package would
have its own tree of files (like you just described). so for example:
~$ cd /packagefs
/packagefs$ ls
Eterm                 defoma         idl           scrollkeeper
aclocal               dict           ifupdown      services
alien                 dictd          info          servicetypes
alsa                  doc            initrd-tools  sgml
alsa-base             doc-base       java          sgml-base
applets               efsd           john          sgml-data
application-registry  emacs          keymaps       sgmltools-lite
applnk                enlightenment  licq          sounds
<snip>
/packagefs$ cd emacs
/packagefs/emacs$ ls
bin doc etc man var

... and so on and so forth; with the subdirs under the package name only
holding files for that package.

this could be generated pretty easily, based on information in the package
database. problem there, is that it's not guaranteed to be up-to-date, since
changes might be made after a package is installed.

upside of this, is that it could be done pretty easily right now; and get
people into the habit of having something like it. union-mounting it over /
would give you a rough equivalent of what you're describing above.

your idea has the merit of making dpkg --repack substantially easier and
more likely to get every file associated with a package (for instance,
adding a virtual/ subdir under /etc/httpd/conf and using include directives
in one's httpd.conf file). for that reason, it may be a better long-term
solution.

Carl Soderstrom.
-- 
Network Engineer
Real-Time Enterprises
www.real-time.com