NYCPHP Meetup

[Tom Melendez]

Hey folks,

It's so interesting how we all have similar reasons, yet different 
conclusions.  My situation is a little different, so I thought I would 
share.

I'm an RPM person, all the way.  I believe in maintaining a large number 
of machines, you need to trust the distro.  That doesn't mean you 
shouldn't run a test server and review the packages, however.  Now for 
the difference in my situation:

I work on an embedded product, which uses an old distro, so I NEED to 
build everything (well, alot of things) myself, and then package it 
myself as an RPM, as this software needs to go to many servers 
remotely.  But frankly, I'd rather use the RPMs provided by the distro, 
as it scales much better, in terms of machines, and in terms of people 
(just give it to the system admin to install, no compiling necessary).

Regarding the list below, here are my thoughts/experiences (I know you 
didn't ask!)
1. Agreed, run a test server, and install RPMs manually
2. many RPMs uses the "enable-all-modules" (I forget the flag), so you 
get all (if not all, alot) modules
3. I haven't heard this, but am using PHP 5.0.4 (actually just build 
5.1beta yesterday) Apache 1.3.33 and the newest mod_ssl and it works 
fine so far.
4. Good point.  I do this at the package level, however (don't install 
software you don't need, which may cause dependency issues, I know!)

Just my two cents.

Tom
http://www.liphp.org

Paul Reinheimer wrote:

>I to am a build from source person for the Apache/PHP/MySQL set. My
>argument in support of this decision (even on an RPM based distro) has
>a couple facets:
>1. I've got my machine set up to automatically update RPMs when they
>become available, I don't want to do this for these three. If there's
>going to be a problem I want it to happen while I'm watching.
>2. My configure command for PHP is kind of... long. I'm not even sure
>if I would get all this with the RPM:
>'./configure' '--with-mysql=/usr/local/mysql'
>'--with-apxs=/etc/httpd/bin/apxs' '--with-gd' '--with-png'
>'--with-zlib-dir=/usr/local/zlib-1.2.2' '--enable-gd-native-ttf'
>'--with-ttf' '--with-jpeg-dir=/usr/local/lib/jpeg-6b/'
>'--with-freetype-dir=/usr/local/lib/freetype-2.1.9/'
>'--with-xpm-dir=/usr/X11R6/' '--with-tidy' '--with-curl'
>'--with-openssl=/usr/local/' '--enable-dba=shared' '--with-db4'
>3. When I looked, I seem to recall having problems matching PHP
>5.0.newest with Apache 1.3.newest.
>4. Long configure commands aside, If I don't need it, I don't want it.
>It's only one more thing to worry about.
>
>I'm happy to let up2date manage the other stuff kicking around on the
>machine, but for the trio that make my webserver work, I'm going to
>stick with source.
>
>
>
>paul
>
>
>
>
>On 7/9/05, Christopher Merlo <cmerlo441 at gmail.com> wrote:
>  
>
>>On 7/8/05, Mitch Pirtle <mitch.pirtle at gmail.com> wrote:
>>
>>    
>>
>>>Ditto for debian, running source of PHP 5.0.4 on ubuntu because
>>>working with the debs available was a complete disaster for me.
>>>      
>>>
>>I have to stand up for Debian, because I'm a fan.  Debian stable, and
>>even testing, are perfect server environments.  Ubuntu was designed
>>strictly for the user's desktop.  You have to be careful which .deb
>>files you use in Ubuntu, because mixing and matching Debian .debs and
>>Ubuntu .debs can lead to nightmares.
>>
>>I've been running PHP, MySQL, and Apache, all from .debs, on a Debian
>>stable system, for about 3.5 years now, with no complaints.  This
>>summer, I'm switching to testing, because it's that stable.  Ubuntu is
>>a pretty desktop toy (which I'm using right now as I type this e-mail
>>on my laptop), but I would never use it on a server.
>>
>>--
>>cmerlo441 at gmail.com
>>http://www.firstofthenext.com/
>>_______________________________________________
>>New York PHP Talk Mailing List
>>AMP Technology
>>Supporting Apache, MySQL and PHP
>>http://lists.nyphp.org/mailman/listinfo/talk
>>http://www.nyphp.org
>>
>>    
>>
>
>
>  
>