Re: Solutions for the Apache upgrade hell
On Sun, Jul 13, 2014, at 13:17, Arno Töll wrote:
> we've got a problem with Apache that causes problems during upgrades
> (e.g. #716880, #752922, #711925). In short, the issue is that Apache 2.4
> changed ABIs, so that we need to ensure that dpkg properly removes
> packages linking against the obsolete ABIs at upgrade time. This is the
> first time this happened since Debian Etch, so this brings a problem to
> the spotlight, that hasn't been one for a long time.
> To summarize the bug reports: The problem is, that Apache package
> maintainers at that time decided, that third party modules shall depend
> on apache2.2-common, by guaranteeing ABIs remain stable as long as the
> package name does not change. This is, so far policy compliant. However,
> by now ABIs did change and we were forced to rename the package (we did
> so, by providing a virtual API package third parties must depend on. At
> time of writing this is apache2-api-20120211). Unfortunately,
> apache2.2-common also contains conffiles and configuration file handling
> in postinst/postrm ...
> I spent a lot of time to properly transition to a new state with
> conffiles/configuration separated from ABI handling, and this works well
> enough for regular updates by now.
> Unfortunately it turns out, that /a lot/ of people use "aptitude
> --purge-unused safe-upgrade", or the apt equivalent "apt-get
> dist-upgrade --purge" which causes dpkg to purge the user's
> configuration, in particular enabled modules, during the upgrade because
> apache2.2-common disappears in that step. Those people end up with
> effects as described in the bugs outlined above, for example with
> incomplete installations because our maintainer scripts had no chance to
> properly detect the state of the /etc/apache2 directory before the
> This gives us three possibilities which all have unwanted side effects
> (unless you come up with an idea that all of us makes happy). I'm
> writing to this list in hope that someone has a very smart idea to make
> everyone happy, or express your support for either alternative to give
> us some insights what people think would be the best alternative.
> * Add a apache2.2-commmon transitional package. This gives us a chance
> to inspect /etc/apache2 in spite of --purge-unused and properly
> transition to Apache 2.4. HOWEVER, this has the nasty side effect that
> modules ABIs are considered compatible as far as dpkg is concerned.
> Therefore, old module packages aren't forced to be removed and this
> breaks at runtime when people try to start their upgraded web server
> with incompatible modules. As a workaround we could add a versioned
> "Breaks" for all modules in Wheezy (~ 75) in the apache2.2-common
> transitional package, and in addition for packages that existed in
> Squeeze or Etch only (no, really). That said, this still won't help for
> third party modules outside Debian which people might use (and to my
> best knowledge, they do a lot) and it's generally problematic in view of
> the policy with respect to library packaging (even though we're not a
> library strictly speaking)
This + BIG FAT WARNING in release notes seems to be the best option
People's configuration will probably break anyway due custom
files, etc. or manually compiled modules.
Also if people have custom modules that will get removed in the upgrade,
they wouldn't want to start the apache without those modules anyway -
this could have all kind of security implications - exposing the raw
files of interpreted languages, etc.
1. As an option you can walk through all enabled modules in apache2.4
postinst and detect incompatible ABI in /usr/lib/apache2/modules/*.so
2. As a thought did you think about moving the modules under
/usr/lib/apache2/20120211/ (e.g. similar to what PHP has). You still
have time for that and it would make the transition easier in the future
(also with third party modules).
Ondřej Surý <firstname.lastname@example.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server