Les Mikesell wrote:
> On 6/28/2010 9:46 AM, Whit Blauvelt wrote:
>> On Mon, Jun 28, 2010 at 09:49:21AM -0400, Jim Perrin wrote:
>>
<snip>
> No, the fact that your ability to 'yum update' and have the right thing
> happen is broken is a big problem regardless of who/where you ask for
> help. Even if you break it yourself, it is bad that it is broken.
As much as I would rather do something myself, at times, Les is right. If
you get a job offer somewhere else, suddenly, think of the next person who
has to maintain this.
>
<snip>
<snip>
> place. And there are three easy ways to not break it. In order of
> increasing difficulty:
>
> 1) find a yum repo with suitable RPMs already built and maintained (e.g.
> remi for mysql) and enable that repo only for the yum install and update
> commands for this particular app.
>
> 2) build from source, but be sure everything lands in /usr/local, /opt,
> or other location completely outside of any packages under rpm control.
> Track updates yourself and be sure you know how to delete all files
> that were installed. Do plenty of testing if you use developer source
> releases - because no one else may have.
<snip>
I think 2 is the way you may need to go for some things. One of our
servers here, and at a place I used to work at, needed a) a newer version
of PHP, and the other place also needed https support in php, which was
*not* in the repository. So, the source tarball got d/l from the project
site, and built in /usr/local, where, IMO, was where it should be. That
way, you can not worry about what yum's doing, because your apache
configuration will point to /usr/local, and there's be no accidents.
mark