Modules fail to enable when configured after apache2 is configured

[Robie Basak]

This is related to Debian bug 745834 and Launchpad bug 1312854, which Stefan kindly fixed in http://anonscm.debian.org/cgit/pkg-apache/apache2.git/commit/?id=804b53b7d5901e47c2751cdf78908ccd9c594c5b that went into 2.4.10-3 that I merged in 2.4.10-7ubuntu1 that is now stuck in vivid-proposed.

The fix seems to work fine in Debian, but not in Ubuntu, though I haven't been able to figure out why. It seems to be a difference in behaviour between dpkg 1.17.21 in Debian and dpkg 1.17.21ubuntu1 in Ubuntu.

The code:

    if ! dpkg-query -f '${Status}' -W apache2|grep -q installed; then

is inside apache2-maintscript-helper, which is called from libapache2-mod-passenger's postinst.

I thought this was a bit dubious as I seem to recall something about dpkg reentrancy within a maintainer script to be unreliable and not recommended, though I can't find any reference to that right now.

I can reproduce this on Ubuntu (with vivid-proposed in sources.list) by running "apt-get install apache2 libapache2-mod-passenger", but also again by running "dpkg -P apache2 libapache2-mod-passenger" and then (from /var/cache/apt/archives) "dpkg -i apache2_2.4.10-7ubuntu1_amd64.deb libapache2-mod-passenger_4.0.53-1_amd64.deb".

In both these cases apache2 is configured first, and then libapache2-mod-passenger. However, on Ubuntu, I get the output "Package apache2 is not configured yet. Will defer actions by package libapache2-mod-passenger." during configuration of libapache2-mod-passenger, even though apache2 was configured. As a consequence, the module never gets enabled as expected, and the puppet dep8 test fails.

On Debian, I cannot reproduce this. The result of "if ! dpkg-query -f '${Status}' -W apache2|grep -q installed" seems to be the opposite in exactly the same scenario.

So I'm not sure whether I can file this as a bug in Debian since I don't know whether the dpkg-query is defined to work, or in fact why Debian and Ubuntu behave differently on this.

Adding a dpkg task, since it'd be nice to have a definitive answer (that applies to Debian too) as to whether this call is defined to work as expected, or if it is documented to not be permitted to be used.

If we cannot do it this way, then maybe touching a file in apache2.postinst (and removing it in prerm or wherever) would be another way to test to see if apache2 is configured yet, that would work for us in this case.

[Robie Basak (racb)]

I tried building 1.17.21 from Debian on Vivid, downgrading to that, and I still get the same (different) behaviour on Vivid. So it seems that it isn't directly a dpkg version difference, but perhaps something else different in Ubuntu (or dpkg configuration?) that is causing this difference in behaviour.

[Colin Watson (cjwatson)]

It took me a while to figure out how to reproduce this reliably; at first I could reproduce it only in the context of autopkgtest, but not in a minimal schroot. It took some strace analysis to figure it out. This is not a dpkg bug after all.

What's happening here is that apache2 in Ubuntu ships ufw profiles, which means that it fires the ufw trigger, but only if ufw is installed (so in order to reproduce this in a minimal schroot you first need to install ufw). This causes apache2 to have "Status: install ok triggers-awaited" rather than the more usual "Status: install ok installed".

I've uploaded apache2 to tolerate the "triggers-awaited" and "triggers-pending" states here. I expect this to clear these autopkgtest failures.

[Launchpad Janitor (janitor)]

This bug was fixed in the package apache2 - 2.4.10-8ubuntu2

---------------
apache2 (2.4.10-8ubuntu2) vivid; urgency=medium

  * Allow "triggers-awaited" and "triggers-pending" states in addition to
    "installed" when determining whether to defer actions or process
    deferred actions (LP: #1393832).
 -- Colin Watson <email address hidden> Wed, 26 Nov 2014 11:31:44 +0000