Debian Sury support, remove dotdeb support, add multiversion support for Sury

[SimonHoenscheid]

References and splits up discussion in #441

I would suggest removing dotdeb. According to this statement https://www.dotdeb.org/2017/01/27/php-7-1-dotdeb/ Wheezy LTS is EOL this month. This deprecates 5.6 for Wheezy. Due to the fact Sury offers 5.6, 7.0, 7.1, 7.2 for jessie and stretch so I would suggest only offering the Sury repo. With the hint it is not needed on stretch for 7.0 if people do not need multiple versions in parallel. Surys packages allow multiple versions in parallel. The module should have this possibility too.

I would suggest a combination:

$sury_repo = true $multi_version = true $php_versions = ['7.1', '7.2']

I guess at least the versions array is a breaking change and config needs to be done for multiple versions. I would recommend moving multiversion support to a second PR when the rest is ready.

@bastelfreak any ideas or recommendations?

And the repo matrix from #433

--	debian 7	debian 8	debian 9
name	wheezy	jessie	stretch
lts	May 2018	April/May 2020	June 2022
ships	5.4 (php5)	5.6 (php5)	7.0 (php)
dotdeb	5.5, 5.6	5.6, 7.0	-
sury	-	5.6, 7.0, 7.1, 7.2	5.6, 7.0, 7.1, 7.2

[SimonHoenscheid]

Please keep up to date References:

• #293
• #436
• #390
• #403

[bastelfreak]

is there a need for $multi_version? If $php_versions is an array with multiple values it's clear that we need to setup multiple versions in parallel.

[SimonHoenscheid]

Thats an option. Should we make sure this only works with debian and sury repo? otherwise the array length should be 1?

I think #436 covers part of the work, especially the data side. Can we put the current work on a seperate branch into this repo?

[c33s]

i think it is a cool thing if we support multiversion but i think multi version support can be cumbersome, often extensions are installed for the wrong php version. see https://github.com/oerdnj/deb.sury.org/wiki/Frequently-Asked-Questions#why-is-php72-cli-always-installed

what will be helpful in general would be a full extension settings map. how is a package called on which debian version on which php version.

for example to install igbinary on php7.1 i need to add a package prefix which is a bad UX/DX.

php::extensions:
  bcmath: {}
  bz2: {}
  curl: {}
  dba: {}
  gd: {}
  imap: {}
  intl: {}
  ldap: {}
  mbstring: {}
  mcrypt: {}
  mysql: {}
  soap: {}
  sqlite3: {}
  xml: {}
  xsl: {}
  zip: {}
  igbinary: { package_prefix: 'php-' }
  imagick: { package_prefix: 'php-' }
  memcached: { package_prefix: 'php-' }
  msgpack: { package_prefix: 'php-' }

• we have to provide settings manipulation for each version seperated
• we also have to do extension handling for each version seperated
• we should make sure that an extension is installed for the right php version
• we should have a extension settings map

maybe we should first refactor the module completly to hiera data, add a roadmap, ... before we go for supporting multi php versions. as virtualization, container and cloud is very widespread, where it is not needed that you install multiple php versions on one system, because you have one container for each version. i am not sure if it is worth the effort (also because only debian has this feature (or does another distro offers this?))

what do you think?

[bastelfreak]

I agree with @c33s that we should first cleanup this module. Afterwards we can rethink the idea of multiple parallel php versions.

[func0der]

So...how is this coming along?

@c33s

as virtualization, container and cloud is very widespread, where it is not needed that you install multiple php versions on one system, because you have one container for each version.

That might be correct for your, but not everybody uses containers and there are people, who want to migrate from one version to the other on the same server. I do not think we should assume stuff here. There are multiple open or now closed issues for this feature, so there seems to be a need for it.

What's the plan?

[brian-lamb-software-engineer]

I personally use hiera to configure them also. I just specify the version on the nodes yaml file and rest is automated. I am eager to see a multi php version solution, on one server, no container myself. Im talking about a way to be able to configure a default vhost, and php-fpm uds, for each version. We can get in there later and make more sockets for other sites if needed, but a clear path to multi php versions, on multi udf sockets, sitting in /run/php-fpm/php56.sock /run/php-fpm/php71.sock etc.. would be helpful.

[kwisatz]

What's the ETA on the rewrite? All the tickets seem to be from around 2020.

[kwisatz]

Asked differently, are PRs accepted and merged before the rewrite, if the rewrite is ever going to happen? I see that e.g. the PRs that @SimonHoenscheid listed in his OP are still open. I have a similar fork that is now more than 3 years old and I wasn't expecting to have to maintain it, but it seems I will need to. I'd much rather create a PR, but what are the odds?

[SimonHoenscheid]

@kwisatz We put a lot of effort into planning the rewrite, but figured out the amount of work is just immense. I don't think it will be possible to do a rewrite with just a small and focussed team in a reasonable amount of time and to keep the module compatible. if there will be a rewrite, it will happen in iterations.

[kwisatz]

So, would you then be opposed to merging some PR that will add support for sury, etc to this legacy version? Or would you rather everyone keeps maintaining their private forks?

[SimonHoenscheid]

@kwisatz sure, just send a PR for the feature