On Tue, 18 Dec 2007, Josh Paetzel wrote: > In most linux distros the package management does not install stuff in > to /usr/local Configs go in /etc binaries in /usr/bin, but you need to > understand that's there's just really no difference between ls and > apache in linux, they are both 3rd party apps. To put them in different > places would introduce an artificial distinction that isn't really > there. In the BSD's ls is developed with the OS, apache is not, ls is > in /bin, apache is in /usr/local Yes! Now I get it. We could do the same kind of thing in Linux by considering the standard GNU utils (Coreutils, Fileutils, Shellutils and Textutils) to be part of the Linux base (GNU/Linux base?) and then put everything else in /usr/local. I'd like that, I think. On Solaris I have ended up with most packages /opt and with most compiled programs in /usr/local, but the stuff in /opt doesn't have a single bin directory -- every program is in it's own directory. So to use the stuff in /opt, I either have to create a symlink from /usr/local/bin, type the full path to the executable, or change my path to add the new directory. All of those choices are hassles. > Your use case of compiling everything by hand doesn't extend well to > production environments at all....not having things under package > management of some sort quickly turns in to a nightmere to maintain. I'm sure you are right. What is the trick to doing it well? Can I compile in a way that creates a package, then install the package? That would seem to provide the best of both worlds, perhaps at a little extra cost in terms of effort during installation. Is it possible to know before installing a package that it will all go into /usr/local? Or can that be something that the package command will allow me to determine? It would be nice if providers would start making their packages work that way. Mike