[arch-general] apache 2.4
David C. Rankin
drankinatty at suddenlinkmail.com
Tue Dec 3 10:37:19 EST 2013
On 12/02/2013 04:43 PM, Anatol Pomozov wrote:
> What I am trying to say is that keeping software up-to-date is one of
> the main maintainer's responsibilities. Especially in Arch Linux that
> "strives to stay bleeding edge, and typically offers the latest stable
> versions of most software" (quote from
Re-read "typically offer the latest stable release of MOST software"
What any distribution has to do is remain reliable and usable to the installed
userbase above all. This apache 2.2/2.4 situation is somewhat of an aberration,
but you need to think about this from a logistical/usability standpoint. Think
about the sheer number of apache 2.2 installs, some very complex. Forcing a
knee-jerk move to 2.4 requires every user with a 2.2 install to set aside the
time and resources required to pick through the changelogs, and implement
configuration changes to each and every Arch apache 2.2 site in existence, and
then to troubleshoot the unintended consequences of the changes. With apache
being the supporting software for numerous groupware and e-commerce sites, the
economic impact is not trivial.
The 2.2->2.4 update represents a "major" update to crucial parts of apache
o removal of modules mod_authn_default, mod_authz_default, mod_mem_cache
o All load balancing moved to individual, self-contained mod_proxy submodules
o --> significant changes in authorization configuration <--
o removal of AuthzLDAPAuthoritative, AuthzDBDAuthoritative, etc...
o numerous modules and options have been renamed
Arch is bleeding edge, much to my chagrin at times, but I fully support the
conservative approach being taken with regard to apache 2.2/2.4. If you just
have to have 2.4 right now, then it is simple to install, go do it. Don't push a
whole distribution to jump forward to the latest apache release where there is a
real-world downside of breakage to the installed userbase.
On 7/9/13 there was a discussion about whether Arch was appropriate for use
with servers, see: "[arch-general] Arch Linux on servers?". That is the crux of
this issue. Arch, while remaining at the "bleeding edge", must provide sane
updates that do not break or destroy critical applications jolting the userbase
to implement time-consuming and costly updates. To Arch's credit, they do a darn
good job striking a balance, but it is a balance nonetheless between usability,
reliability and bleeding-edge. Without reliability and usability for core server
applications, a distribution is relegated to being nothing more than a desktop
plaything for hobbyists or enthusiasts.
For something as fundamental to server operations as apache, Arch should
continue to provide 2.2 as the core package while providing 2.4 in testing for
an extended period. A clear timeline for the move of 2.4 from testing to core
should be developed by reasoned discussion with input from the user base. Once
2.4 moves to core, 2.2 should be maintained in core as (eg. apache22) for so
long as support is provided by apache.org.
David C. Rankin, J.D.,P.E.
More information about the arch-general