[arch-general] apache 2.4

William Giokas 1007380 at gmail.com
Tue Dec 3 16:23:46 EST 2013

On Tue, Dec 03, 2013 at 09:37:19AM -0600, David C. Rankin wrote:
> 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
> > https://wiki.archlinux.org/index.php/Arch_Linux).
>   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
> including:
>   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
>   see: http://httpd.apache.org/docs/2.4/upgrading.html
>   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.

Now this is something I can get behind. Servers are not (or should not)
be running [testing] or anything of that nature, and so should not be
affected by the changes that going to 2.4 in [testing] would bring.
However, people with a testing environment would have a clear upgrade
path and the ability to test and give feedback to the Arch packagers and
maintainers for issues or other things that happen with 2.4 while it's
in [testing], instead of just complaining to upstream or that some AUR
package is not working.

William Giokas | KaiSforza | http://kaictl.net/
GnuPG Key: 0x73CD09CF
Fingerprint: F73F 50EF BBE2 9846 8306  E6B8 6902 06D8 73CD 09CF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20131203/88142aa9/attachment.asc>

More information about the arch-general mailing list