On 2/20/07, Bart Smaalders <[EMAIL PROTECTED]> wrote:
UNIX admin wrote: >> On a personal workstation, you would expect >> pkgadd .... >> stall things in (say) /usr/bin where you can use them >> directly in your PATH. > > This will work for Sun and Sun packages, but will actually break for any third party packages, for example when trying to install them in a sparse zone. > > Besides, the System V spec mandates that no 3rd party should ever write to the /usr, the UNIX system resources directory. > > That directory is for the vendor and vendor alone to use, and must be off limits to everyone else, PATH convenience or no. PATH issues can be solved in other ways, whereas using /usr is just about one of the biggest faux-pas a 3rd party can make in a UNIX environment. > > One of the things I'd like to suggest is that we consider means for applications to appear in the default path more easily than requiring users to edit their .*rc files. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts _______________________________________________ opensolaris-discuss mailing list [email protected]
I agree, though I'm not sure there's an easy solution. To perhaps start a discussion on this, the two main approaches I've seen (though I'm sure there's others) is putting a default path value in /etc/PATH, or having some sort of global rc directory that applications can place scripts in that get sourced when the shell is invoked ( i.e. /etc/profile.d if I recall correctly). The problem with /etc/PATH is that it quickly gets very large and ugly. It is not uncommon to see /etc/PATH stretch 10-15 lines (or more), just to add in all the /opt/packagename/bin directories. With a profile.d style setup, you have an issue of a malformed script could cause lots of heartache, as well as potential performance issues if there are lots of scripts that have to be run every time. Also, would we need to care about duplicate entries in path, order, etc?
_______________________________________________ opensolaris-discuss mailing list [email protected]
