[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Simon Waters wrote: > Neil Williams wrote: > >> On Thu, 2008-11-06 at 13:41 +0000, "Philip Radford" wrote: >> >> >>> I am keen to utilise the latest versions of Apache and >>> PHP for my web applications which work in a LAMP environment. >>> >> That is the *wrong* reason to use unstable. >> > > Philip, > > Is there a specific feature of PHP or Apache that you need which isn't > in Etch? I think this is the right question. > > The point of stable is to ensure that software you > write/configure/"bundle together" works, and continues to work without > modification, until that release dies. > > Whilst plenty of folks say unstable works, unstable doesn't crash etc, > this misses the point. Unstable may both break completely (I've had it > mess up a box to the point where I needed to reinstall hundreds of > packages to get working again - okay it was only a handful of commands > but it took many hours to run), or more crucially may break your > applications by changing something important. > > As others have said, this close to releasing Lenny (Testing), where it > has less critical bugs that Etch (Stable), there is a case for > installing Lenny (although there is a lot of churn despite the alleged > freeze). I suspect that most web servers would be better of running Etch > because if there is a problem, other people will have solved it and > documented the fix. > > MySQL and PHP are in my experience just the kind of things to have > non-backward compatible changes in unstable, so when thing break you > find migrating back to a working version means running unstable as it > was on a specific day (or exporting the database and trying to import > into an earlier versions of MySQL, or rewriting PHP code), and you lose > the ability to apply new security related patches until you address the > relevant issues. > > Complex PHP installs likely also want some security work done on them. > > Debian (afaik) still installs with a version of the PHP.INI file which > isn't suitable for use on a live server (think developer version - > display_errors is on, and the security settings are weak), and you may > want Suhosin or similar installed. Things like Suhosin will depend on > the version of PHP, and unstable will likely upgrade PHP and a few days > later get a compatible Suhosin. Similarly new PHP or MySQL releases may > need additions to the configuration files (and the php.ini will likely > be heavily changed by yourself). > > I would also try to avoid backports, and other repositories if you can. > Backports is probably the least painful, but all of these make it harder > to upgrade when the time comes, and your stable release is no longer > getting security support. I know I picked up PHP and MySQL from a third > party repository with Sarge, and ended up having to switch all my PHP > from mod-php5 to CGI at one point. > > Now if you'd said LAPP (Linux, Apache, Postgres and Perl) I might have a > different view ;) > > I don't think the group has a distro of choice. We do have some very > vocal Debian fans - but hey when you have a good thing and it costs > nothing to share it.... > > Thanks for your comments and advice on this Neil. There are no specific features I require other than those provided by the default modules. It was more a case of ensuring that all the security holes were patched. Then I read about such patches are released back into previous releases so therefore I should be covered. I also take on board your comments regarding php.ini. I am quite paranoid about php and security so my settings are up to speed for a production environment. As per my previous post, I have now reverted to etch and am quite content to use the supplied packages unless there is a need to upgrade. I am keen to look at lenny (testing) but it is not important. Regards Phil Cornwall -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html