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

Solutions for the Apache upgrade hell


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 upgrade.

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.

* Ignore the problem, and refer to the manpage of aptitude without
proper fix etc. which clearly says "THIS OPTION CAN CAUSE DATA LOSS! DO
can't tell this before it's too late, such as in a NEWS file - and we
know, everybody reads release notes too, right?

* 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)

* Treat the upgrade as new install in our maintainer scripts when
--purge-unused was used (side question: Any idea how to reliably and
properly detect that case, as the binary package name changed and it's
well possible that in Wheezy apache2.2-common is installed, but not
apache2 because of weird(tm) packaging)? This would not preserve user's
choices in regard of enabled/disabled modules and thus be a borderline
policy violation, too.

What would you do in our situation? Side note 2: We kinda expected this
situation and added a trapdoor in Wheezy [1], but it turned out, that
even that is not good enough to prevent havoc with --purge-unused.


with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: