Simple HowTo

[Gene Poole]

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 at macys.com