Roundcube 1.4.11 and multiple PHP versions

Take a look at https://askubuntu.com/questions/563178/the-following-packages-have-unmet-dependencies

 

What is the output of

Code:

ls -l /etc/alternatives/*php*

 

What is the output of

Code:

sudo apt-get install -f

 

I have this same issue on Debian 10, packages seem to be changing and things are a bit of a mess right now. Previously I had roundcube 1.4.11 from buster-backports, and php versions from sury.org - the latest php updates caused roundcube to be uninstalled, and reinstalling it results in version 1.3.16. And if you've used the elastic skin from 1.4, you know you can't go back.

Trying to force roundcube install from buster-backports has version issues and now also needs php-intl and php-json packages, which seems to be new (I have all the php#.#-intl and php#.#-json packages already .. my guess is previously they each had eg. 'Provides: php-json' and now they do not). Installing the default php-intl and php-json versions result in newer version 2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826 and a quick check shows that version of several other php packages now:

Code:

# dpkg --list | grep 2:8.0+80
ii  php                                2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826                         all          server-side, HTML-embedded scripting language (default)
ii  php-bcmath                         2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826                         all          Bcmath module for PHP [default]
ii  php-cgi                            2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826                         all          server-side, HTML-embedded scripting language (CGI binary) (default)
ii  php-cli                            2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826                         all          command-line interpreter for the PHP scripting language (default)
ii  php-fpm                            2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826                         all          server-side, HTML-embedded scripting language (FPM-CGI binary) (default)
ii  php-gmp                            2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826                         all          GMP module for PHP [default]
ii  php-mbstring                       2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826                         all          MBSTRING module for PHP [default]
ii  php-mysql                          2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826                         all          MySQL module for PHP [default]
ii  php-xml                            2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826                         all          DOM, SimpleXML, WDDX, XML, and XSL module for PHP [default]

Using apt policy I see there is also a 2:7.3+69 version of those packages:

Code:

# apt policy php php-cli php-intl php-json
php:
  Installed: 2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826
  Candidate: 2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826
  Version table:
 *** 2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826 500
        500 https://packages.sury.org/php buster/main amd64 Packages
        100 /var/lib/dpkg/status
     2:7.3+69 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
php-cli:
  Installed: 2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826
  Candidate: 2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826
  Version table:
 *** 2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826 500
        500 https://packages.sury.org/php buster/main amd64 Packages
        100 /var/lib/dpkg/status
     2:7.3+69 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
php-intl:
  Installed: 2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826
  Candidate: 2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826
  Version table:
 *** 2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826 500
        500 https://packages.sury.org/php buster/main amd64 Packages
        100 /var/lib/dpkg/status
     2:7.3+69 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
php-json:
  Installed: 2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826
  Candidate: 2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826
  Version table:
 *** 2:8.0+80~exp2+0~20210213.31+debian10~1.gbpf31826 500
        500 https://packages.sury.org/php buster/main amd64 Packages
        100 /var/lib/dpkg/status
     2:7.3+69 500
        500 http://deb.debian.org/debian buster/main amd64 Packages

All the other packages have the same versions available as well. So I install those package versions version (php-bcmath didn't update, I had to uninstall it first, then install the older version):

Code:

# apt install php=2:7.3+69  php-cgi=2:7.3+69 php-cli=2:7.3+69 php-fpm=2:7.3+69 php-gmp=2:7.3+69 php-mbstring=2:7.3+69 php-mysql=2:7.3+69 php-xml=2:7.3+69 php-intl=2:7.3+69 php-json2:7.3+69
# apt remove php-bcmath
# apt install php-bcmath=2:7.3+69

Then I was able to update roundcube to 1.4.11 again:

Code:

# apt -t buster-backports install roundcube roundcube-plugins roundcube-plugins-extra roundcube-core

Roundcube is now back to 1.4 with the elastic theme. When uninstalling roundcube during package updates (yes, because I didn't read what was going to be removed), I chose to not remove the roundcube database, so all my config and settings are still there and things seem to be working fine.

 

It comes to mind that we'll probably need to pin those meta packages to the correct version to avoid this at the next update.

 

I think this is more of a problem with Roundcube, as the error shows even when php7.3, php7.3-cli, etc is installed.

I have opened a issue with them on GitHub to see what they think about it. https://github.com/roundcube/roundcubemail/issues/7906

 

Right now I have these packages pinned, which prevents roundcube from being uninstalled/downgraded (/etc/apt/preferences.d/php-prefer-7):

Code:

# this is for howtoforge.com/community/threads/roundcube-1-4-11-and-multiple-php-versions.86397/

# review apt policy for packages which have sury.org candidates pin if the wrong version will be installed
#     dpkg --list | cut -d' ' -f3 | grep ^php- | xargs apt policy | less

Package: php php-bcmath php-cgi php-cli php-fpm php-gmp php-intl php-json php-mbstring php-mysql php-xml
Pin: version 2:7.*
Pin-Priority: 1001

Package: php-common
Pin: version 2:69
Pin-Priority: 1001

It probably wouldn't hurt to play with uninstalling those pinned meta packages (an others?) and see what other dependency issues turn up (ie. other packages that might need updated like roundcube).

 

Reply from the Roundcube Debian package maintainer:
Hi,

On Thu, 25 Feb 2021 at 18:12:41 +0100, Thom via Pkg-roundcube-maintainers wrote:

> When installing Roundcube 1.4.11 from the buster-backports repo on Debian 10, it depends on php modules < PHP 8.0.

See https://salsa.debian.org/roundcube-team/roundcube/-/commit/1add6714e98a3b54b750fca49cf74a11fad050c8 for the rationale.

> When using the Sury repo, php-cli and others are PHP 8. I do have PHP 7.3 installed with the necessary modules, so I think that a dependency on php7.3-cli, php7.3-intl, etc should be sufficient.

We're not depending on PHP 7.3, Bullseye has 7.4 and works as well. A fleet of alternatives php7.3-* | php7.4-* isn't an option because it has to be the same version for all modules. Hopefully Roundcube upstream will backport the PHP8 compatibility fixes to 1.4 at some point and we'll be able to remove the restriction then. For now I suppose your best bet is to edit the control file locally if you're using third-party repository with php-* 8.x: https://wiki.debian.org/EditingBinaryPackageMetadata

Cheers,
--
Guilhem.

 

Just received another email, with good news:

On second thought this is not ideal since Bullseye will be released with PHP 7.4 and I guess several users will want to upgrade php-* to 8.0 via bookworm or 3rd party repositories.

After checking with other maintainers what was the best way to express the dependency, I reverted the aforementioned commit and instead added a hint which packages *might* need to be manually installed. The upload should migrate to testing in 10 days and I'll upload a new version to buster-backports then.

Thank you for bringing that up in time for the hard freeze, would have been more problematic to fix that afterwards

--
Guilhem.