Drupal 6 for EPEL
Some of you might have noticed that Fedora 11 and up already have an up to date Drupal6 version, but EPEL , which is what a lot of people are using on their CentOS or RHEL builds only has a Drupal5. I asked Jon Ciesla, who is maintaing the Drupal packages in Fedora why :
Because when Drupal was initially built for EL-5 and EL-5, the 5.x
branch was the current release. It's up to date, 5.20 is the most
recent release, and is still supported upstream in terms of security
fixes. 6 is out, and has been for awhile, but we have the following:
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies
Since 5.x isn't broken or insecure, it'll be a tough sell to move to
6.x. Once upstream drops support, this may change.
It's a correct answer from a Distribution point of view, but the fact is it is widening the gap between the Ops and the Devs. If the ops want to keep their platform clean we need to have our software packaged on the platform we want to use, which is most often an Enterprise Linux distro, on the other there is understandably no hair on a dev's head that he will be building a new site on a Drupal 5 platform.
So until the Drupal community doesn't declare Drupal 5 dead, RHEL and CentOS users will have to use 3rd party Drupal6 RPMS , or rebuild the F12 rpm from Source again .
Comments
#1 Kris Buytaert : @arrfab pointed to rpmforge
Arrfab pointed me to the forgotten Drupal 6 package in RPMForge
Yes that's a good package.. but it's yet another repo to be included ..
Also it's work that is being done twice.. once for Fedora, once for RPMForge.. it would be easy to single maintenance just in Fedora and enable it for EPEL too .
#2 chx : RHEL is unsuitable for websites.
They still do not have a release w/ PHP 5.2 more than three years after 5.2.0 got released. Two years after Drupal 6 is out it's not there. They are worse than Debian and hold back innovation. When it will have MongoDB, 2020?
#3 Kris Buytaert : Fully Agree
Absolutely .. we choose EL for stability and reliability.
The question always is what's bleeding edge, what's recent and what's obsolete. In the Drupal case .. Drupal 5 is obsolete, Drupal 6 is tested and verified and backed by enterprise level support. and D7 is Bleeding Edge ...
We can only open the conversation with the Distributions on which version they should include ..
#4 Anonymous : Drupal and RPM
Responsible software packages for any enterprise OS will always lag behind the bleeding edge; often by a large amount. People go with an enterprise-class OS because the number of security and other bugs found in software and packages diminishes as the release 'cooks' in the field. That's why, as long as a given major release (often minor too) is still around, it will be the one chosen for update. It's why RH and others cherry-pick and back-port fixes from new software instead of rolling new versions whenever possible.
Enterprise OSes are chosen for stability. We have ubunt-u and fedora - and potentially rawhide, really - for those wanting This Week's Release. While I think that EPEL and RH both need to maintain the reliability over the shiny, I'd fully support a plan to create a new repository of more recent releases, so that even RHEL(/centos/etc) people can get shiny new releases, as long as they understand support is tainted.
Not many people understand this, and it's stranger to understand from a developer point of view that people would value anything more than a week old in the 'release early, release often' world of open source. As the customer wants more reliable software vs more flashy, and as the OS Distro wants less bugfixes and needs to find the middle ground between the shiny and the sharp, the policy of locking in major releases is a less-worse solution than others.
As a former unix and linux distro build engineer, it's one of the few policies I haven't challenged -- after the logic was explained.