This page collects work needed towards the Wheezy release in preparation of the Apache 2.4 transition and associated packages.


Below a list of proposals of tasks to be addressed towards Apache 2.4

Migrated release goals from Lenny -> Squeeze

(see also Apache2SqueezeGoals)

Let the MPM packages die

The separate mpm packages should go away. All mpm modules should go into the -bin package.

Done as of 2.4.1-1 (in experimental).

Drop the ITK MPM

There is mod_privileges in 2.4 which uses Solaris privileges to achieve something like mpm-itk. Maybe mpm-itk for 2.4 can use a similar approach and exist as a normal module instead of as an mpm. But that's something itk upstream has to worry about. Until that's decided, we may just drop ITK for now.

Done as of 2.4.1-1 (in experimental). There is an experimental patch available, which needs to be carefully tested for 2.4 compatibility. Thus, ITK may or may not come back again.

Dealing with MPMs as simple modules

Some modules (aka: PHP) do still not work with some MPMs, e.g. threaded and require the prefork MPM. As MPMs are simple modules in 2.4 we do not have conflicting packages anymore a reverse dependency could depend on. Thus, we need to provide a runtime configuration check packages can make use of. For example the a2enmod mechanism could be extended by a conflicts declaration.

We also may provide a little helper script in apache2-dev reverse dependencies can use in their postinst script to find out about the MPM used.

Done as of 2.4.1 (in experimental). Packagers should use "a2query" via our apache2-maintscript-helper.

Drop unwanted -dev packages

We also want only one -dev package. This might cause some troubles to PHP maintainers either them or we need to sort out. Probably mod_php should still be compiled without thread support and abort with an error message if used with a threaded mpm.

Done as of 2.4.1 (in experimental).

Streamline binary packages built from the source package

The fact that apache2.2-common contains the apache2 config files creates some problems. Suppose it is replaced with apache2.4-common, which would conflict with apache2.2-common and also contain the config files. This means that the config files have to move from one package to the other during update. During the upgrade from 2.0 to 2.2 this has caused problems because apt-get --purge dist-upgrade then apt-get purges the old package first (including any user-modified config) and only then installs the new package. We will have to work around that during the 2.2 to 2.4 upgrade, too, but maybe we can get rid of the problem for the future. I was thinking of something like:

Module packages would only depend on apache2-mmn-20120123. This would mean we wouldn't need to rename packages if there is ever a 2.6 (and also not when going from 2.3 in experimental to 2.4). There should be a script or another easy way for module packages to add the correct dependency.

Done as of 2.4.1 (in experimental).

Cross/Circular Dependencies

Thus, it is fully intentional that depending on apache2-bin does not setup a fully working web server, only required binaries. That way packages can setup their own instance of Apache as they need it (e.g. as gnome-user-share does). Web scripts (e.g. phpmyadmin) which want a fully working Apache instance shall depend on apache2 instead

Our side is ready and uploaded to experimental. Now, package maintainers need to update their packages and test whether their modules work with 2.4.

Dealing with reverse dependencies

Special care must be taken when depending on Apache. A reverse dependency can be either a web script or an Apache server module which links against a particular version of the Apache web server.

We try to help developers by providing a debhelper to get things right.

Streamline the envvars approach

Instead of defining lots of stuff in the envvars file and using that in scripts and the config, it should be possible to get most infos from the output of "apache2 -t -DDUMP_RUN_CFG" and use that in scripts.

Streamline the package building process

The current rules file is complicated to say the least. Having MPMs integrated as module might simplify the rules file a lot. Make it more readable and usable.

The new 2.4 package is much easier to be understood than the 2.2 package. That helps.

systemd support

Provide systemd support, as an alternative to sysvinit for those who want and like it.

Drop unneeded patches

Some patches shouldn't be patches really. We can probably get rid of the config.sub/config.guess patch by using "dh --with autotools_dev" after sorting out it is still needed at all. Probably there are still some patches left that could be integrated upstream, too.

Mostly done. Patches may need some polishing perhaps.

Improve conf.d mechanism

Automatically enabling config snippets provided by other packages is not suitable for all sites. A way to configure some choices would be nice:

Also, maybe only *.conf files should be included, to reduce conflicts with backup files.

Fix boot / init script issues or document solutions

There are some issues with boot dependency ordering if a webapp requires e.g. an SQL server to run. This should be fixed or the necessary configuration changes should be documented. See #610297.

There are some issues on systems with network manager. Maybe one could add a scriptlet that makes network-manager trigger a graceful reload when the network configuration changes. Maybe this is also fixed by fixing #629899 in apr

Maybe make the init script wait until apache2 has started. This would make it less likely that the init script is not printing an error but apache2 does not start. Also it would be good for cluster control scripts. See #645460.

Use new access control config

The access control config should probably use the new mechanisms. This would make it possible to only allow access to certain dirs (e.g. /var/www, /usr/share) while still making it easy for the admin to override what "allow access" means. This would probably require "?AuthMerging And" to be set.

Configuration files were migrated to the new authorization system. Still needs a migration to an inherited permission system

Make policy for modules/webapps maintainer scripts configurable

Restarting or reloading apache when installing a new module/webapp is not suitable for all sites, especially large production sites. Maybe provide a config option for the admin to disable this and provide a script for other packages to easily use that config.

Frankly, a yellow box is a bit optimistic. Nothing is done yet. However, our new postinst policy asks reverse dependencies to use our apache2-maintscript-helper. Thus, a configurable policy can be amended by extending our helper more easy than before.

Result from some discussion:

when are dependencies allowed to change the MPM

Only modules should be allowed to switch the MPM, web applications must not switch the MPM at runtime (but see TODOs below).

To actually switch the MPM, packagers can use a2query to find out whether it is necessary, and if it is try to switch it. By "switching" using the corresponding API call is meant, under no circumstances packages should try to do their own. If that one fails (i.e. config-test fails) the maintainer script should emit a big warning but not fail.

how to deal with module dependencies in web applications

One possible solution would be too support Depends in conf-available files (if we manage to mitigate its abuse).

Problem: We don't want a webapp to enable a dependency, which switches MPMs, ... but simply enabling mod_alias or mod_rewrite seems ok.

Should we support a transitional fallback configuration which allows web apps to work with both 2.2 and 2.4 packages

in postinst: check for 2.2 with dpkg-query, if yes: create symlink from conf.d/XXX to conf-available/XXX in prerm: remove symlink during remove or purge in config: use <?IfVersion> guard if necessary, then the package has to a2enmod version if 2.2 is installed. For 2.4, we will compile mod_version in statically.

A simple example how to use such a fallback:

        if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
                . /usr/share/apache2/apache2-maintscript-helper
                apache2_invoke enconf package.conf
        elif  dpkg-query -f '${Version}'  -W 'apache2.2-common' > /dev/null 2>&1 ; then
              # if the configuration uses <IfVersion> uncomment the next line
              # a2enmod -q version
              [ -d /etc/apache2/conf.d/ ] && [ ! -l /etc/apache2/conf.d/package.conf ] && ln -s ../conf-available/package.conf /etc/apache2/conf.d/package.conf

NOTE: The above is broken because it will also go into the else branch if apache2 is not installed at all. dpkg-query should be used instead.

QUESTION: Is the above note still correct? The code seems to handle the "apache absent" case just fine? -ZugSchlus 20130903

and in postrm:

     [ -l /etc/apache2/conf.d/package.conf ] && rm /etc/apache2/conf.d/package.conf

When to disable modules and web app confs in maintainer scripts (similarly, when to enable)


modules should unconditionally call apache2_invoke (unless a maintainer or debconf script verified not to install any configuration at all, e.g. for scripts supporting several web servers), it will obey site local policies in future. The maintainer helper will make sure that during upgrade of a module package, disabled modules are not enabled again.

modules need to be disabled on removal (and purge anyway), or config will be broken (?LoadModule would fail)


Derive the same behavior as modules IF the web application can be run with a feasible out-of-box configuration, don't enable it otherwise Should also be disabled on removal (and purge anyway), because important files may be missing (and that's the point of package removal, anyway).

modules and webapps must call apache2_invoke dis* both on removal and on purge. apache2_invoke will remember stuff it removed during removal and will reenable it during reinstall.

For that, the maint-script-helper needs to store $@ somewhere when it is first sourced. Document somewhere that $@ must be intact at that time. Complain if $1 is empty (that's meant as sanity check because $1 contains the maintainer script argument and is guaranteed to be set by dpkg).

The rembering could be done like: touch /var/lib/apache2/modules_disabled_by_maintscript/$module purge should then do rm -f /var/lib/apache2/modules_disabled_by_maintscript/$module in addition.


(in addition to printing them to the screen unless the maintainer set APACHE2_MAINTSCRIPT_HELPER_QUIET=1)

Rethink virtual hosts

There is a not very well known way to use one virtualhost section for both ssl and non-ssl. We could consider if we want to use that (quite possibly a bad idea because it would collide with basically all how-tos out there) or provide it as an alternative config example. If not, it may make sense to move most of the settings of the default vhost to a separate include file.

Also see

Web application policy

Together with maintainers of other web servers we should approach a "web application policy". For reasons outlined above a web application need to depend on web servers this way (or recommend - that's subject to discussion):

On the other hand packages which build-depend on apache2-dev need to declare dependencies to

instead. We may write a static Lintian check which checks whether dependencies are in place. For example we could check for a build-dependency on apache2-dev or whether a package installs files to /usr/lib/apache2/modules. Furthermore, we could write a script in apache2-dev (or eventually debhelper, say dh_apache2) which fills in the right dependency automatically.

See the mailing list for ongoing discussion on possible web application policies (

Work on dh_apache2 has begun, talking to nginx folks they seem interested to consolidate dependencies as well. Hopefully we get some feedback on our d-d-a announcement.

Add more docs / example configs


Filed some bugs:;

Add entry to the release notes

Upgrading will need manual changes by the admin in most cases. Document that in the release notes

Make upstream happier

It turned out, upstream is very unhappy with the Apache configuration for Debian. That's mostly a heritage dating back to Etch days and things slightly improved since then. Some of their critics is summarized in Maybe we could take the opportunity and improve things again. Maybe we can make upstream happy happier. These are things suggested by upstream:

Finally, the current configuration contains lots of bug references involving configuration changes. These need to be triaged.

Add hints to the Release Notes

Apache2 is an important package where every change affects lots of users. The release notes should feature a (brief) hint about this change.



Fix some bugs (see BTS):

Maybe migrate to git (it's already format 3.0 (native)).