[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bits from the Apache Maintainers / Upcoming apache2 2.4 transition

This is the first "Bits from the Apache Maintainers" announcement 
ever. There are lots of changes coming up and following a well-
established practice we are going to announce some of them here.

In this update:
-  New Apache HTTPD 2.4 available in experimental <HTTPD24>
-  Package Transition <TRANSITION>
-  Packaging Guidelines <GUIDELINES>
-  Call For Help <HELP>

New HTTPD 2.4 available in experimental <HTTPD24>

A major Apache HTTPD upgrade has been released in February. A brief 
overview of new features is available at [1]. Some of the changes have 
major impacts of the Debian packaging. Notably, all Multi Processing 
Modules (MPM), which were compiled as separate apache2 executables 
previously, can now be loaded as simple modules. This implies that the 
conflicting MPM packages like apache2-mpm-prefork are gone. Instead, 
users can pick the MPM they wish at runtime in future. Moreover, there 
some incompatible changes in the configuration which makes it likely 
that local configuration files have to be adjusted. Please see our 
changelog, the NEWS, and the README.Debian [2] files for more detailed 
instructions. More upgrade hints can be obtained upstream at [3]. 

Thanks to a lot of work by Arno Toell, an experimental apache2 2.4 
package is available in Debian's Experimental branch for most 
architectures (and the rest will be built soon). We invite everyone to 
test our package, but it is of course not ready for use in a 
production environment. We advise you to test upgrades and report any 
problems you faced. That said, please keep in mind that this upgrade 
will break any installed third party modules (mod_php, ...) unless the 
respective maintainers do provide an experimental package linked 
against Apache 2.4, as well. Some changes such as the default out-of-
box configuration we intend to ship with Wheezy's 2.4 package are not 
finalized yet and will be addressed in another follow-up upload to 
experimental and/or unstable in the near future.

Beware: The ITK MPM is not included for the time being. This may or 
may not change until the freeze. 

[1] http://httpd.apache.org/docs/2.4/new_features_2_4.html
[2] </usr/share/doc/apache2/README.Debian>
[3] http://httpd.apache.org/docs/2.4/upgrading.html

Package Transition <TRANSITION>

The new upstream release breaks the Application Binary Interface (ABI) 
for the first time since Debian featured the 2.2.3 package in Debian 
Etch. Thus, all reverse depending packages need a sourceful upload. To 
track the progress, we filed a transition bug in #661958. Refer there 
for a verbose description what we plan to do. In short, there are 
several things packages need to be aware:

* The apache2 2.4 source package features an incompatible ABI ("module 
magic number") to all existing Apache 2 module packages. We've made a 
list of affected packages in the the denoted transition bug. All 
module packages need a source(!) transition. This is mostly because we 
expect module packagers to depend on our virtual API package in 
future, instead of declaring unversioned dependencies against our 
meta-package. There is a new dh_apache2 helper to help creating this 
dependency. Moreover, we have dropped the apache2-threaded-dev and 
apache2-prefork-dev development packages. Instead all packagers should 
build depend on apache2-dev only. Please refer to the <GUIDELINES> 
section for detailed packaging guidelines
* Please review whether your module packages are still needed, or if a 
similar or roughly identical functionality is provided by a new core 
* If a module package does not build with 2.4 and there is no new 
upstream version that does, it may be time to ping the upstream 
developers. If upstream is inactive and/or you have difficulties 
getting the module adapted to 2.4, feel free to contact us. Some hints 
can be found at [4].
* The handling of modules that only work with a particular MPM is not 
yet finalized. At the very least, such modules should refuse to load 
with an incompatible MPM and print a meaningful error message.
* We want to consolidate reverse dependencies of web applications. See 
<GUIDELINES> as well.
* We plan to do a mass-bug-filing by the time we consider the package 
ready for unstable. Following our time line we hope to upload to 
unstable early in April.

[4] http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html

Packaging Guidelines <GUIDELINES>

We've written packaging guidelines how we would like reverse 
dependencies to declare their package relations to our binary 
packages. These guidelines are not yet set in stone. Especially for 
the parts concerning webapps we encourage discussion. Refer to [5,6] 
for the details. In a nutshell:

Module packagers need to change build-dependencies and test their 
modules against Apache 2.4. Build-depend on "apache2-dev" 
unconditionally (apache2-threaded-dev and apache2-prefork-dev are 
gone). Binary module packages must not depend on apache2 or apache2-
bin. Instead modules must depend on our virtual API package (apache2-
api-20120211) only. This should make things easier for the next major 

Packagers of web applications with configuration files (e.g. files 
installed to /etc/apache2/conf.d/) should note that the right 
directory for these kind of configuration files is now 
/etc/apache2/conf-available. Moreover, web applications should not 
declare dependencies against the apache2 HTTP server only. Many web 
applications may work with other web servers, too. Therefore they 
should recommend(!) supported alternatives by declaring packaging 
relationships like this:

  Recommends: apache2 | other_web_servers_you_support | httpd

Note, we do not have a strong opinion whether to put web server 
dependencies of web applications to a hard dependency or a 
recommendation. We would  like to hear your feedback on that - 
especially if you are maintaining another web server or a web 
application in Debian. Generally, we are keen to consolidate a uniform 
and predictable behavior for all web applications but we do not want 
to push any decision in one or another direction. For more context on 
this discussion please see [7].

Please do not call our configuration wrapper scripts (a2enmod/...) 
directly. Instead use our maintscript-helper which is designed to do 
things in a way we would like reverse dependencies to interface with 
us. It is planned to allow the administrator to configure what should 
or should not be done. Again, see [5,6] for detailed instructions. 
Also, read our hints carefully, as some web applications should not 
have a hard depdendency against our web server. This case must be 
covered in your maintainer scripts. 

[5] http://wiki.debian.org/Apache/PackagingFor24
[6] </usr/share/doc/apache2/PACKAGING>
[7] http://lists.debian.org/debian-devel/2012/01/msg00148.html

Call For Help <HELP>

You would like to help us? We can still use help, especially for the 
2.4 transition. There is our RFH bug #646208 still left open and there 
is a wiki page [8] with our ongoing and upcoming changes we plan to 
work on.

[8] http://wiki.debian.org/Apache2Transition

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: