apparently broken dependency resolution

Bug #1434115 reported by David King on 2015-03-19
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
unattended-upgrades (Ubuntu)
Medium
Unassigned

Bug Description

It looks as though unattended upgrades' dependency resolution is a little broken when there are multiple alternatives and when the dependency is currently satisfied by a package other than the first alternative.

In this case, package php5 was upgraded. php5 depends:

$ dpkg -s php5|grep Depends
Depends: libapache2-mod-php5 (>= 5.5.9+dfsg-1ubuntu4.7) | libapache2-mod-php5filter (>= 5.5.9+dfsg-1ubuntu4.7) | php5-cgi (>= 5.5.9+dfsg-1ubuntu4.7) | php5-fpm (>= 5.5.9+dfsg-1ubuntu4.7), php5-common (>= 5.5.9+dfsg-1ubuntu4.7)

I use php5-fpm, and specifically do not want libapache2-mod-php5 installed (not least because it breaks my FPM config). After manually purging libapache2-mod-php5:

$ dpkg -l $(dpkg -s php5|grep Depends|perl -npe 's/Depends://; s/[,|]/\n/g'|cut -f 2 -d\ )|grep ^[a-z]
un libapache2-mod-php5 <none> <none> (no description available)
un libapache2-mod-php5filter <none> <none> (no description available)
un php5-cgi <none> <none> (no description available)
ii php5-common 5.5.9+dfsg-1ubuntu4.7 amd64 Common files for packages built from the php5 source
ii php5-fpm 5.5.9+dfsg-1ubuntu4.7 amd64 server-side, HTML-embedded scripting language (FPM-CGI binary)

note that:
• php5-fpm is installed and therefore that dependency of php5 was already satisfied
• php5-cgi and libapache2-mod-php5filter are alternative dependencies along with libapache2-mod-php5, yet neither got installed in the way that libapache2-mod-php5 did.

For completeness' sake, here's an excerpt of the unattended upgrade log (full log attached) showing that it was this morning's upgrade run that installed libapache2-mod-php5:

Selecting previously unselected package libapache2-mod-php5.
Preparing to unpack .../libapache2-mod-php5_5.5.9+dfsg-1ubuntu4.7_amd64.deb ...
Unpacking libapache2-mod-php5 (5.5.9+dfsg-1ubuntu4.7) ...
Preparing to unpack .../php5_5.5.9+dfsg-1ubuntu4.7_all.deb ...
Unpacking php5 (5.5.9+dfsg-1ubuntu4.7) over (5.5.9+dfsg-1ubuntu4.6) ...

Other requested information:

$ lsb_release -rd
Description: Ubuntu 14.04.2 LTS
Release: 14.04

$ apt-cache policy unattended-upgrades
unattended-upgrades:
  Installed: 0.82.1ubuntu2.1
  Candidate: 0.82.1ubuntu2.1
  Version table:
 *** 0.82.1ubuntu2.1 0
        500 http://ubuntu.orion.retrosnub.co.uk/ubuntu/ trusty-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     0.82.1ubuntu2 0
        500 http://ubuntu.orion.retrosnub.co.uk/ubuntu/ trusty/main amd64 Packages

David King (strix) wrote :

Evidence from another machine I administer (same version of OS and unattended-upgrades and that uses a similar PHP configuration) suggests that the bug may only manifest if the previous state was 'un' rather than 'rc':

$ dpkg -l libapache2-mod-php5|grep ^[a-z]
rc libapache2-mod-php5 5.3.10-1ubuntu3.6 i386

on this machine, unattended upgrades did not attempt to install libapache2-mod-php5.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in unattended-upgrades (Ubuntu):
status: New → Confirmed
Changed in unattended-upgrades (Ubuntu):
importance: Undecided → Medium
Raphaël Droz (raphael-droz) wrote :

On production machine which most probably using php5-fpm + event or worker Apache2 MPM, this bug forcefully reinstall libapache2-mod-php5 after (unattended = minor) PHP5 update.
The direct effect of this is reinstalling mpm_prefork !

Simply stated: unattended-upgrades breaks LAMP installation by not resolving dependencies correctly.
Could maintainer have a look on this please?
I've been hit every time php5 package is updated.

Current workaround:
```
      Package: libapache2-mod-php5 libapache2-mod-php5filter
      Pin: origin ""
      Pin-Priority: -1
```
Note: may add php5-cgi, since the auto-installation of this package is not as disastrous.
Note: it's hard to *debug* this bug (unless setting XUUPOPT="-d" inside /etc/cron.daily/apt) and may well be left unnoticed in some case... until website traffic increases implying the prefork MPM extra-load.

Side question: why would unattended-upgrades provide its own (not-apt-based) resolution mechanism in the first place?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers