Re: updating using RPM on RedHat

josh@saratoga.lib.ny.us wrote:

> I installed Squid from the RPMs when I installed RedHat (using
> 2.2.STABLE1 which was available for the ftp RedHat install at
> http://metalab.unc.edu at the time.) I also downloaded the source
> code so I could build the ncsa_auth program. I would like to keep my
> installation current and prefer to use RPMs.
>
> If I upgrade using RPM will everything in my /etc/squid/squid.conf
> be preserved and continue to be used or do I have to back things up
> and then restore them? Has anyone set up a script to use the rpmfind
> program to automatically check for an update? When I ran rpmfind it
> found STABLE4, but it didn't find STABLE5. Is there an official RPM
> site for the latest release?
>
> Is there any advantage or disadvantage between using the tarball and
> the RPM. I know, for example, MySQL says to use the RPM binary
> distribution if possible for best performance. Is there and easy
> script or make file setting so that the code goes to the same place
> regardless? Right now I have everything in /usr and /etc from the
> RPM. The tarball wants everything in /usr/local. I am sure that if I
> manually went through and tried to make sure all the references to
> /usr/local/squid/etc were switched to /etc/squid I would screw it up
> completely by missing some. For me this is another reason to stick
> with the RPM.

I have a custom RPM based on the source RPM that redhat provides for
2.2stable4, but with everything in the usual /usr/local like the squid
tarball. I use the RPM system as we have a number of caches (8+) that we
manage. I like to be able to know exactly what version of squid we have,
how it was built, and be able to make another box exactly the same (or
re-build a given machine). The RPM build gives me a number of binary
rpms that allow me to target certain standard configs, and control what
extras are installed on the box. Upgrading to a new version of squid (eg
2.2S5) means modifying the source RPM SPEC file, as appropriate for the
new sources, building new configs, testing on another box, and then
propogating to the production machines. Learning how to work with RPM
takes a bit, and some extra initial work is required, but for a
production box, it is worth the effort.

--
Darren Steven
Applications Specialist
Networking Tasmania
Telstra Australia
Ph.1800 813 302