How to handle inconsistencies in PHP packaging

[ganto]

I'm currently migrating the debops-contrib.roundcube role from debops.php5 to debops.php (see debops-contrib/ansible-roundcube#24). As even the latest version of Travis-CI (using Ubuntu Trusty 14.04) has a rather antique version of PHP, the packaging seems a bit different from newer releases. Feeding the following variable to the role works perfectly fine on Debian Stretch:

php__dependent_packages:
  - mbstring
  - json
  - pspell
  - zip
  - sqlite3

On Travis-CI (and probably also Debian Jessie) it will result in the following error:

TASK [debops.php : Install PHP packages] ***************************************

failed: [testing-gce-2c8b58ef-e44b-4026-a9cb-c22e444a17a0] (item=[u'php5-cli', u'php5-fpm', u'php5', u'php5-curl', u'php5-gd', u'php5-mcrypt', u'mbstring', u'php5-json', u'php5-pspell', u'zip', u'sqlite3', u'php5-pspell', u'zip']) => {
  failed: true
  item:
    - php5-cli
    - php5-fpm
    - php5
    - php5-curl
    - php5-gd
    - php5-mcrypt
    - mbstring
    - php5-json
    - php5-pspell
    - zip
    - sqlite3
    - php5-pspell
    - zip
  msg: "No package matching 'mbstring' is available"
}

As you can see, mbstring and zip are not available as a separate PHP package and sqlite3 is packaged as php-sqlite.

My question is now, does a consumer of the debops.php role has to care for such packaging issues or should this be solved in the PHP role? The current interface currently makes me think that the user of the role shouldn't need to think of the exact packaging implementation as the php-/php5- prefix is already nicely hidden.

Do you think it would be possible to make this transparent to a consumer and filter out respectively map package names for individual distributions? My idea would be, that I simply can give a list of modules that my application requires and, as long as there is a proper package for it, the role would decide itself what to install. What do you think?

[ganto]

The PR merged above (#41) introduces a new variable php__included_packages which holds a list of bundled PHP packages in php-common. If a consuming role now requests a package that is listed there, the package is stripped from the list given to the APT package manager.

This solves the issues with the zip and mbstring packages mentioned above.

The other issue mentioned above is not properly solved yet. The PHP package names are now either mapped 1:1 to APT packages or absorbed by php-common (new). What is still missing is the use case where a PHP package name is mapped to a different APT package. In my example above I mentioned sqlite3 which is packaged as php-sqlite3 with PHP 7.x but php5-sqlite with PHP 5.x. Other examples would be pdo_sqlite which is packaged with sqlite3 or dom which is packaged with xml and so on...

This is a bit more complicated to implement. It would require a manually populated mapping of PHP package names to APT package names which depend on distribution releases. Before the list of packages to be installed (php__combined_packages) is given to the package manager to install the packages, it has to be rebuilt via this mapping table. Anyone confident to implement this?