RE: Path idea
I hope I am not hereby spamming this mailing list, but it seems germain to
some of the problems being encountered with packaging, installation, etc
and was prompted by the attached note.
Here is one person's opinion after 20 years of struggling with path
'epistemology'. These are notes based on something immodestly called 'The
Standard Directory System'.
The root directory is a public trust. Nothing, even the operating system
should be arbitrarily sticking stuff in the root beyond a single directory.
For an application, even a directory in the root is considered bad
Paths should be hierarchically arranged by 'ownership', except in the case
of operating system deficiencies which *require* references outside of the
'proper' directory tree.
For instance, the main part of the path should be relative such as:
User commands should take precedence as over-rides, hence path becomes:
Next in precedence is the normal operating system stuff, for instance:
Finally, those things which *must* have a global path are added at the end:
This path is already too fat for my tastes, but it sure beats what I
Using the protocol above, you can have a directory tree that looks like:
/home/thisguy <<--- My home directory
/home/thisguy/bin <<--- My personal commands
/home/thisguy/compile <<--- compilers I use
/home/thisguy/compile/bin <<--- commands common to all my
/home/thisguy/compile/CC1 <<--- Simple directory for
/home/thisguy/compile/CC1/bin <<--- Commands common to
/home/thisguy/compile/CC1/wrk <<--- Working directory for
/home/thisguy/compile/CC2 <<--- Complex directory for
/home/thisguy/compile/CC2/bin <<--- Commands common to
/home/thisguy/compile/CC2/dev <<--- Development under compiler
/home/thisguy/compile/CC2/dev/bin <<--- Commands for dev under
/home/thisguy/compile/CC2/dev/wrk <<--- Work directory for
/home/thisguy/compile/CC2/dev/wrk/bin <<--- Commands specific to this
/home/thisguy/compile/CC2/rel <<--- Release test under
/home/thisguy/compile/CC2/rel/bin <<--- Commands for rel under
/home/thisguy/compile/CC2/rel/wrk <<--- Work directory for
With the relative path, when you reside in a given work directory, commands
and over-rides pertinent to that work directory will be found first on the
path. As soon as you switch to a different compiler directory, the
commands pertinent to the new directory will take precedence.
Any software that is installed and localized within a tree similar to the
above can be added and removed without impacting anything else. For
/usr/app <<--- Global app directory
/usr/app/bin <<--- Global app commands
/usr/app/bin/apphelpr <<--- A helper for apps [Version
/usr/app/legapp <<--- Directory for a 'legacy'
/usr/app/newapp <<--- Directory for a newer
/usr/app/newapp/bin <<--- Commands for the newer
/usr/app/newapp/bin/apphelper <<--- Required newer apphelper
for apps [Version 2.00]
/usr/app/newapp/wrk <<--- Working directory for
Note that with the above, the newer application can be installed,
uninstalled and re-installed without either impacting or being impacted by
any other files on the system.
For local directories that require a lot of specific settings, a local
'env' script can be placed in the appropriate 'bin' directory on the tree.
So the protocol to use a subsystem is (conceptually) as follows (for the
example of the new application above):
As a philosophical point, whenever you reduce code/storage/maintenance by
placing common stuff in a common location, you create a dependancy.
By duplicating some files which are common, but do not properly reside at a
higher level, you pay the following price (initially):
1) Storage requirements may increase
2) Bug fixes may require updates in multiple places.
You derive the following benefits:
1) A bug fix/update for one application is less likely to create a problem
in an unknown dependant application.
2) You can operate on things one at a time for add/update/delete.
3) Removing unused items requires no prior knowledge of dependancies.
4) Eventually, over time, this 'local' method may theoretically cause
storage and maintenance to actually *decrease*, since the former method
makes legacy code more difficult to update or remove.
5) Migrations/updates can be easier, can be selectively applied and are
simple to roll-back (even selectively).
Any way you slice it, it's going to be complicated managing multiple items,
versions, releases, builds and configurations. However, with some
organization, it may be possible to reduce dependancies and minimize
clutter at a given level.
On Monday, January 18, 1999 6:50 AM, Thomas MANGIN
> All of you have a very strong Unix oriented view of OS (that is normal
> for Hurd devel) but I really have the impression that you dont really
> want to change things.
> Whatever you think about the Unix floder organisation (even if logical)
> is a fucking mess. (too much things are cross-linked or split between :
> /sbin, /bin, /usr/bin/, /usr/sbin, /usr/local/bin, ...)
> And the reason is that there are too many application to fit properly in
> one place.
> On anothre side, I perfectly understood that to create hurd you have to
> work under Linux but your discution about /usr
> reminds me somehing I saw in inferno OS (a long time ago)
> it was possible to lauch application like this
> > editor/vi
> > wm/start
> I mean extending the PATH already set.
> I had found that a wonderful idea.
> I know it it is utopia. But I hope to be explained why my point of view
> must be eradicated forever cleary.
> To UNSUBSCRIBE, email to email@example.com
> with a subject of "unsubscribe". Trouble? Contact