apparently broken dependency resolution

[David King]

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

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

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

[Raphaël Droz (raphael-droz)]

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?

[Launchpad Janitor (janitor)]

This bug was fixed in the package unattended-upgrades - 1.18

---------------
unattended-upgrades (1.18) experimental; urgency=medium

  [ louib ]
  * Update blacklist translations
  * Fix syntax in template conf files

  [ Balint Reczey ]
  * Keep mypy 0.761 happy
  * test: Create empty dirs to save kept packages list to them
  * Log explanation about kept back packages (LP: #1850964)
    (Closes: #945837, #903875)
  * Use GitHub Actions for CI instead of Travis.
    Run tests in Ubuntu Focal release because older releases don't have the
    needed python-apt version.
  * debian/tests/common-functions: Use backported python-apt from a PPA on Eoan
  * debian/tests: Skip upgrade-between-snapshots test.
    Python-apt's version is sid is too low for unattended-upgrades to work.
  * Use apt_pkg.Hashes instead of deprecated apt_pkg.md5sum()
  * autopkgtest: Skip upgrate-all-security in sid because buster can't be tested
  * Make allowed_origins, blacklist and whitelist attributes of
    UnattendedUpgradesCache
  * Make strict_whitelist attribute of UnattendedUpgradesCache
  * Apply pinning to disable not allowed origins and honor blacklist/whitelist.
    This makes candidate adjustments obsolete, since apt's resolver would pick
    candidates only from allowed origins by itself unless local pinning
    configuration overrides that.
  * Rely fully on pinning to disable allowed origins and stop adjusting
    candidates.
  * Drop Unattended-Upgrade::Allow-downgrade since now pinning is honored and
    downgrades are allowed for package versions with priority >= 1000.
    (Closes: #905877, #919046, #768087, #946491) (LP: #1251228, #1434115)
  * Don't ignore allowed origin when the package's priority is < 100.
    This used to be the way of honoring the priority, but now this special case
    prevents the package from showing up as a package kept back.
  * Assume frontend locking to be supported.
    Python3-apt (>= 1.9.6~) is required which supports the frontend locking API

 -- Balint Reczey <email address hidden> Tue, 25 Feb 2020 19:28:13 +0100