Frankenphp repos exist for multiple versions now

[henderkes]

I've finally finished deb repos for all supported php versions (8.2 to 8.5, 8.2 will no longer receive updates starting 01.01.2027).

Therefore frankenphp's install.sh will change, see here: php/frankenphp#2099

Likewise, you should update your scripts to choose a version explicitly. Check https://debs.henderkes.com for manual instructions.

The old repository will start printing deprecation notices on install/update starting today, but will continue functioning.

Additional context

This does not affect the recommended way of using Docker images.

[stasadev]

Thank you very much @henderkes !

---

This does not affect the recommended way of using Docker images.

In the DDEV context, it's more common to use pre-built packages because they provide a much better user experience, without waiting for long Docker builds for all PHP extensions. This also applies to CI/CD if people use DDEV there.

I will try switching to Debian packages here. If it works well, we can then create a new webserver type for FrankenPHP and archive this add-on.

[henderkes]

In the DDEV context, it's more common to use pre-built packages because they provide a much better user experience, without waiting for long Docker builds for all PHP extensions. This also applies to CI/CD if people use DDEV there.

I gave DDEV a spin yesterday and - first of all - great user experience. A small hiccup with the Windows installer aside (it only looks for an Ubuntu installation in WSL and doesn't find RHEL?) aside, the installation was smooth and easy.

II think I can now understand why you're going for system packages, rather than Docker images. I had to rebuild a few times to switch to frankenphp, switch to trixie, add extensions etc. and it did take a considerable amount of time.

[stasadev]

A small hiccup with the Windows installer aside (it only looks for an Ubuntu installation in WSL and doesn't find RHEL?) aside

Please open a new issue in the ddev/ddev repo, we take small steps from time to time to improve our installer and RPM support wasn't on our radar.

I had to rebuild a few times to switch to frankenphp, switch to trixie, add extensions etc. and it did take a considerable amount of time.

Yes, time is the most valuable thing we have, and we don't want to waste it waiting.

We focus on how to get started quickly: New GUI Installer: Get DDEV Running on Windows in Just 10 Minutes (Video)

[stasadev]

I'm pretty happy with the result in:

• feat: migrate to Debian packages, fixes #46, fixes #47 #51

Thank you very much @henderkes !
The ddev start has become very fast.

---

Note: there is one difference between php-zts and php build.

In DDEV we use phpenmod <extension> / phpdismod <extension> scripts to quickly enable/disable any PHP extension, it's very convenient.

These scripts come from php-common package:

$ dpkg -L php-common
/.
/etc
/etc/cron.d
/etc/cron.d/php
/usr
/usr/lib
/usr/lib/php
/usr/lib/php/packaging
/usr/lib/php/php-fpm-socket-helper
/usr/lib/php/php-helper
/usr/lib/php/php-maintscript-helper
/usr/lib/php/sessionclean
/usr/lib/systemd
/usr/lib/systemd/system
/usr/lib/systemd/system/phpsessionclean.service
/usr/lib/systemd/system/phpsessionclean.timer
/usr/sbin
/usr/sbin/phpenmod
/usr/sbin/phpquery
/usr/share
/usr/share/doc
/usr/share/doc/php-common
/usr/share/doc/php-common/changelog.gz
/usr/share/doc/php-common/copyright
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/php-common
/var
/var/lib
/var/lib/php
/var/lib/php/modules
/var/lib/php/sessions
/usr/sbin/phpdismod

They obviously don't work with php-zts because of different paths. I updated them in .ddev/web-build/Dockerfile.frankenphp so they now work with DDEV.

I don't know if there were any plans to support php-common; just noting that this is what Debian and Ondrej/PHP use.

[henderkes]

The php-common package isn't actually a php package, just a virtual package that packaging managers use to pre-select multiple packages at once. These are all part of the php-zts metapackage for me.

I thought phpenmod was a weird thing for apache SAPI. I guess not. I'll look into compiling it and adding it.

[henderkes]

https://github.com/legale/phpenmod/blob/master/phpenmod

this is completely messed up with a bunch of bugs. I'll have to copy ondrej's version.

[henderkes]

Not usable either, because Ondrej changed it specifically for his versioned naming scheme. I'll write my own variant, I suppose.

[henderkes]

Devel package is fixed. phpenmod and phpdismod will be ready in ~50 minutes. The github runners are a bit slow atm.

[stasadev]

Devel package is fixed.

Thanks, tested it with all PHP versions, looks good.

[henderkes]

Unlike ondrej which uses php-common as sort of a package shared across all php versions from his repo and updates mods-available, my version will be called phpenmod-zts and phpdismod-zts and directly alter /etc/php-zts/conf.d/X0-ext.ini. Statically compiled extensions (calendar,ctype,curl,dom,exif,filter,iconv,libxml,mbregex,mbstring,opcache,openssl,password-argon2,pcntl,phar,posix,readline,session,simplexml,sockets,sodium,tokenizer,xml,xmlreader,xmlwriter,zlib) cannot be enabled or disabled. Ondrej compiles a few of them as shared extensions and they could therefore be disabled... not that they should.

[stasadev]

Thank you for adding phpenmod-zts and phpdismod-zts, it's good, but unfortunately it doesn't cover all use cases, for example, xhprof.ini:

$ phpdismod-zts xhprof
$ cat /etc/php-zts/conf.d/20-xhprof.ini 
; extension=xhprof.so
xhprof.output_dir=/tmp/xhprof
auto_prepend_file=/usr/local/bin/xhprof/xhprof_prepend.php

extension is commented out, but auto_prepend_file is not, which results in unwanted behavior.

Or if there's no extension, we can't control it, assert.ini:

$ cat /etc/php-zts/conf.d/20-assert.ini
[Assertion]
zend.assertions = 1

I'm going to keep the existing logic with mods-available.