Modules fail to enable when configured after apache2 is configured

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.