Craig White wrote: > I suppose that's one way of looking at things. > > Another way of looking at things is that they don't exist in a vacuum > and Linux software is like building blocks and thus software that > depends upon apache libraries knows where to find them and they are > matched in version and compatibility. > > go ahead and install in /usr/apache and /usr/tomcat if you wish...it's > your box. Install location by years of convention from the roots of UNIX > clearly suggests that software compiled from source is installed > in /usr/local tree. Your comments strike me as someone who is willing to > endure pain in order to eschew convention...run with your instincts. > > Another way of looking at things is that the package management of a > Linux distribution (i.e. Fedora or RHEL or Ubuntu or Debian or ???) has > the software packages all ready compiled and standardized as for file > locations, users, links for other libraries (and resolves compatibility > issues) and even does the extremely heavy lifting of installing errata > (bug fixes) and security updates quite simply. > > Quite simply the reason to use a distribution like Fedora or Red Hat > Enterprise Linux is that you can simply do something like... > > yum install httpd tomcat5 > > and you get the software and any required packages downloaded, > installed, configuration files into place, and ready to rock and roll. > > yum update > > would then update all packages on your system for which updates exist > > You might be more into a system like slackware or linux from scratch > where you manage everything yourself. But of course, when security > updates come out for apache or tomcat, you would have to then download > and compile again. You take responsibility for your own installs. > > Craig Les Mikesell wrote: > If you want to use any packaged (rpm) programs you have to make sure > that locally compiled programs don't conflict, so /usr/local works for > that - and is the default for most source installs. > >> Also, if they are going to do that then the documentation needs to tell me >> ahead of time what file systems need how much space since we divide up the >> hard disk before installing software. >> >> I feel like I'm going backwards - use the provided RPM or else! > > Or else it's your responsibility to keep it out of the way of the > packaged versions and rebuild it yourself every time it needs an update. > There are still some things where this is worth the trouble, but I > don't think apache and tomcat would be. What do you get with your own > build that isn't in the RPM version? Craig: I'm not raising up against RPM packaging. What I am concerned about is the 'migration' to a 'C:' drive in Linux. Let me explain: Since you aren't telling me ahead of time where and how much space Java, Tomcat, or Apache is going to need, I have no choice but to make a very large '/' (root) partition which is the same as a 'C:' drive. Except with M$, I can tell it to install on the 'D:' or 'E:' drive if I have one. Normally, since I haven't seen much go into /usr/local or /opt in the past (RH8-9, FC1-4), I usually make them around 512 MB in size. But now without any warning or documentation I may need a /usr/local or /opt of maybe 2-GB. Les: I use the standard 'sudo yum update' today without problems. What I have learned is that , unless it was installed with a RPM package (I download the Apache, Tomcat, and Java binaries as tar.gz packages), it doesn't get updated. Thanks, Gene Poole gene.poole@xxxxxxxxx
