wmk@fed.frb.gov (William M. Kules) (06/21/91)
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) I know the docs say you shouldn't do this, but after 18 months of having to hand install libraries, I'm about ready to. Any warnings, sample config files, etc. would be appreciated. Maybe they could do this for R5... Bill Kules, Automation and Research Computing | Internet: wmk@fed.FRB.GOV Federal Reserve Board, Washington, DC | UUCP: uunet!fed!wmk "Recycling: Just do it, dammit!" | Phone: (202) 452-3933
evans@testmax.zk3.dec.com (Marc Evans) (06/24/91)
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 ===========================================================================