[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:


Path becomes:


Finally, those things which *must* have a global path are added at the end:


Path becomes:


This path is already too fat for my tastes, but it sure beats what I 
normally see.

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 
compiler 1
/home/thisguy/compile/CC1/bin              <<--- Commands common to 
compiler 1
/home/thisguy/compile/CC1/wrk              <<--- Working directory for 
compiler 1
/home/thisguy/compile/CC2                  <<--- Complex directory for 
compiler 2
/home/thisguy/compile/CC2/bin              <<--- Commands common to 
compiler 2
/home/thisguy/compile/CC2/dev              <<--- Development under compiler 
/home/thisguy/compile/CC2/dev/bin          <<--- Commands for dev under 
compiler 2
/home/thisguy/compile/CC2/dev/wrk          <<--- Work directory for 
dev/compiler 2
/home/thisguy/compile/CC2/dev/wrk/bin      <<--- Commands specific to this 
work directory
/home/thisguy/compile/CC2/rel              <<--- Release test under 
compiler 2
/home/thisguy/compile/CC2/rel/bin          <<--- Commands for rel under 
compiler 2
/home/thisguy/compile/CC2/rel/wrk          <<--- Work directory for 
rel/compiler 2

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 
instance, consider:

/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):

cd /usr/app/newapp/wrk
. env

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 
[SMTP:t-mang98@bat710.univ-lyon1.fr] wrote:
> 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 debian-hurd-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact 

Reply to: