Hi Arno, On Sun, Jul 13, 2014, at 13:17, Arno Töll wrote: > Hello, > > 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. > > * 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 to me. People's configuration will probably break anyway due custom configuration files, etc. or manually compiled modules[1][2]. 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 source 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 files. 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). Cheers, -- Ondřej Surý <ond...@sury.org> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405325501.4775.141318941.5caff...@webmail.messagingengine.com
