🚀 go-pugleaf

In article <1014@arccs1.fed.FRB.GOV>, wmk@fed.frb.gov (William M. Kules) writes:
|> 
|> We support X11 (and lots of other software) on about 160 Sun 3s and 4s.
|> The easiest way for us to do this is by putting each package (e.g. X11,
|> OpenWindows, Emacs) in its own hierarchy, outside the normal /usr partition,
|> then providing symbolic links from /usr/<application> to point to the
|> real application.  This provides benefits for users, because they don't
|> have to change their PATH when switching between architectures.  It
|> benefits us, too, because it localizes all changes to one area when we
|> have to update an application.
|> 
|> Has anyone futzed with the config files to do this?  It would be pretty
|> easy, except that the .a and .so files get stuck in USRLIB by default.
|> The benefit would be that we'd have a lot more flexibility in where we
|> installed it.
|> 
|> The hierarchy could then look something like this:
|> 
|> /usr/X11 --
|>           |
|>           |-- bin
|>           |
|>           |-- include
|>           |
|>           |-- lib
|>           |
|>           |-- usrlib (for shared and static libraries)

When I created DEC's Advanced Development Kit version of OSF/1, I kitted in
exactly the manner that you describe. The imake changes were quite simple to
achieve this, and the benefits I personally feel outweigh the difficulty
intorduced in tracking MIT. I must admit however that I did also provide
symlinks from the *standard* directory locations pointing to the *real*
locations. Clearly, this is not an option for many system V implementations.

- Marc

-- 
===========================================================================
Marc Evans - WB1GRH - evans@decvax.DEC.COM  | Synergytics     (603)635-8876
      Unix and X Software Consultant        | 21 Hinds Ln, Pelham, NH 03076
===========================================================================