Add support for Wolfi-based images

[toabctl]

Summary

Add support for Wolfi — an apk-based, rolling-release distribution maintained by Chainguard whose container images live under cgr.dev/.... Wolfi mostly follows alpine's upstream-source package naming, with a handful of well-known divergences this PR handles explicitly.

Strategy

For each EXT@alpine) block, decide what its wolfi twin should look like:

1. Shared package names → POSIX | alternation. When alpine and wolfi use the same package names for an extension's deps (~67 of the existing entries: gd, redis, intl, opcache, mbstring, pdo_mysql, …), collapse to:

   EXT@alpine | EXT@wolfi)
       <shared body>
       ;;
   

2. Different package names → separate EXT@wolfi) block with renames. Wolfi has the same library under a different name for ~15 deps:

   alpine	wolfi
   enchant, enchant-dev	enchant2, enchant2-dev
   geos, geos-dev	geos-3.14, geos-3.14-dev
   imagemagick, imagemagick-dev	imagemagick-7, imagemagick-7-dev
   judy, judy-dev	libjudy, libjudy-dev
   lapack	liblapack
   libbz2	libbz2-1
   libmemcached-libs	libmemcached
   libsasl	cyrus-sasl-libs
   lz4-libs	liblz4-1
   maven	maven-3.9
   openjdk8	openjdk-8-default-jdk
   postgresql-dev, postgresql-libs	postgresql-17-dev, libpq-17
   python3, python3-dev	python-3.13, python-3.13-dev
   vips, vips-dev	libvips, libvips-dev
   zstd-libs	libzstd1

3. alpine-musl-only deps → silently dropped from wolfi twin. libexecinfo, libintl, bsd-compat-headers are needed only on alpine because of musl libc; glibc-based wolfi has equivalents built into libc. libvpx/libvpx-dev are only used by gd's PHP <= 5.6 path which isn't supported on wolfi anyway.

4. No wolfi equivalent → no twin emitted. A few libs simply aren't packaged in wolfi: aspell-*, cassandra-cpp-driver, c-client, imap-dev, lua5.1-*, recode, tidyhtml. The corresponding extensions (pspell, cassandra, imap, luasandbox, recode, tidy) remain alpine-only — install-php-extensions will fail on wolfi for those, with the same "package not found" error pattern as any genuinely-missing dep.

setDistro() is unchanged — wolfi sets ID=wolfi in /etc/os-release and the rest of the script's distro-keyed lookups now have wolfi patterns.

Top-level switches

case "$DISTRO" in alpine) ... (apk update, simulate, virtual phpize-deps cleanup) and case "$DISTRO_VERSION" in alpine@*) ... (openssl variant, $PHPIZE_DEPS, icu-data) use plain alternation — their bodies don't reference per-extension package names.

Testing

Manually verified end-to-end on a Wolfi-based PHP image:

• install-php-extensions gd redis resolves the right deps via apk on Wolfi (using the renamed names where applicable), runs phpize/configure/make against ZTS PHP, produces /usr/lib/php/modules/{gd,redis}.so with tsrm_get_ls_cache and tsrm_mutex_* references (ZTS-compatible).
• extension=gd and extension=redis registered in $PHP_INI_DIR/conf.d/.
• The runtime ZTS interpreter loads both extensions; imagecreatetruecolor/imagepng produces a valid PNG, and new Redis() instantiates correctly.
• Both the bundled-source path (gd) and PECL path (redis) verified.

CI integration is not included in this PR — happy to add a wolfi build matrix entry if you'd like, just want to flag it as a separate question since it'd require deciding which Wolfi base image to test against.

Out of scope

• No changes to existing alpine/debian behavior — every alpine pattern still matches.
• Extensions whose deps aren't packaged in wolfi (pspell, cassandra, imap, luasandbox, recode, tidy) remain alpine-only.

Filed as a draft to invite feedback on the rename mappings and CI integration approach.

[mlocati]

I won't accept this (but of course you can fork this project and do whatever you like: it's a MIT peoject)

[toabctl]

I won't accept this (but of course you can fork this project and do whatever you like: it's a MIT peoject)

@mlocati why not? anything I can fix to get this accepted?

[mlocati]

Because there's a ton of custom images out there, this script is already rather complex, and some tests may already take 1 hour.