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
manners.
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:
bin:../bin:../../bin:../../../bin
User commands should take precedence as over-rides, hence path becomes:
$MYDIR:bin:../bin:../../bin:../../../bin
Next in precedence is the normal operating system stuff, for instance:
OPSYSPATH=/bin:/sbin:/usr/bin
Path becomes:
$MYDIR:bin:../bin:../../bin:../../../bin:$OPSYSPATH
Finally, those things which *must* have a global path are added at the end:
$GLOBALMALCONTENTS=/home/shared/hacks:/nonstd/bin:/etcetc/bin
Path becomes:
$MYDIR:bin:../bin:../../bin:../../../bin:$OPSYSPATH:$GLOBALMALCONTENTS
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
compilers
/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
2
/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
1.00]
/usr/app/legapp <<--- Directory for a 'legacy'
application
/usr/app/newapp <<--- Directory for a newer
application
/usr/app/newapp/bin <<--- Commands for the newer
application
/usr/app/newapp/bin/apphelper <<--- Required newer apphelper
for apps [Version 2.00]
/usr/app/newapp/wrk <<--- Working directory for
newapp
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
listmaster@lists.debian.org
>
Reply to: