Make using an alternate PHP version easier

[JedMeister]

As each Debian major release only ever includes one version of PHP, it is sometimes desirable (or required) to install an alternate version of PHP. We have eased that for ourselves at build time by supporting alternate versions of PHP via deb.sury.org and using alternate plans. That works well for us and we now include the core config by default (disabled when not required), so TurnKey users also get some of that benefit - even in apps that don't require it.

However, it's still a bit sub-optimal. One point is automated updates - covered in #1159. But there are other shortcomings too.

As background; the way that the PHP ecosystem is currently packaged in Debian/Ubuntu is via php-module metapackages that depend on a counterpart phpx.y-module package - which actually provides the relevant module. In a stable Debian release, these metapackages depend on the included version of PHP. So in Bookworm, php-mysql is a metapackage that depends on php8.2-mysql, php-cli is a metapackage that depends on php8.2-cli and so on.

Sury's deb.sury.org repo includes multiple versions of PHP all in a single repo. These same metapackages exist there as well, but they always depend on the latest PHP version that is available from the repo. So currently, php-mysql is a metapackage that depends on php8.3-mysql, php-cli is a metapackage that depends on php8.3-cli and so on.

That's all well and good if you want to stick with the Debian provided version and it means that your PHP version will get auto upgraded if you do a Debian style in place upgrade. It's also fine if you want to use the latest PHP version (via deb.sury.org). But what about in the future if you wanted to stay with PHP8.3 (so you need to use Sury's repo) after PHP8.4 is released? You couldn't use the metapackages as they will now depend on PHP8.4 (and obviously can't use Bookworm packages because they're still PHP8.2).

The only workaround is to not use the metapackages and explicitly install the packages that include the version in the name. For us, this means that we need to update the plans for any appliance that uses an alternate PHP version.

I'm not sure if it's the best approach, but it has occurred to me, that perhaps a better way to handle installing alternate PHP versions on TurnKey is for us to provide some new apt repos (one per supported PHP version) that just include PHP metapackages?

In case it's not clear, let me explain what I'm thinking in a little more explicitly. Let's assume that I'm implementing this today - with PHP8.2 in Debian stable and PHP8.3 relatively recently released. I would provide a new apt repo called bookworm-php83 (or similar), with metapackages such as php-mysql, php-cli, php-curl, etc, versioned and/or pinned so that they will always be installed before the similarly named metapackages in deb.sury.org (which always depend on the latest available PHP version - currently PHP8.3) or Debian (which always depend on the Debian provided PHP version). These TurnKey provided metapackages would depend on their phpx.y-module counterparts. I.e. php-mysql would depend on php8.3-mysql, php-clion , php8.3-cli, etc. So the actual packages would still come from Debian, or Sury but a PHP version change would simply require changing the enabled apt sources and running apt upgrade.

If you wanted to just use Debian PHP (or latest PHP via Sury), then the TurnKey PHP apt repo(s) would be disabled.

If we were to implement this, I think it would make sense to also provide a simple helper script to enable/disable different versions of PHP.

Pinning it to 18.x may be a bit wishful thinking?!

[a3s7p]

Individually versioned repos is one way to do that but it seems like a complicated way of avoiding depending on required PHP package versions explicitly which I think should be preferred.

Is it really such a common use case that a user wants to upgrade their PHP version but not their appliance version? or that upstream requires PHP newer than what the latest stable Debian has? How many appliances really require a specific PHP version?

[JedMeister]

Thanks for sharing your thoughts @a3s7p 😁

Individually versioned repos is one way to do that but it seems like a complicated way of avoiding depending on required PHP package versions explicitly which I think should be preferred.

I get that it may seem a little convoluted and I haven't actually tried/tested it - so it's possible that I'm missing something and it may be more complex in practice than it seems in my head? But to me at least it seems like a relatively simple and low maintenance way to resolve at least one issue that we're already working around when we use a non-standard (i.e. non Debian default repo) version of PHP (by creating a local php-mysql metapackage with an epoch - so it is currently always bigger than the version in Debian).

Is it really such a common use case that a user wants to upgrade their PHP version but not their appliance version? or that upstream requires PHP newer than what the latest stable Debian has? How many appliances really require a specific PHP version?

Whilst we don't use many Debian packages that use PHP, from what I've seen, they always depend on the php-whatever packages (that don't include the version in their name). I assume that is for the purposes of making major version upgrades (e.g. 11/Bullseye -> 12/Bookworm) "just work". IIRC the only PHP related package that we currently pull from Debian is adminer. It depends on php-mysql (or php-sqlite3 or php-pgsql). Our metapackage already breaks that (hence my desire to eliminate the issue that we're essentially exacerbating).

As Bookworm has PHP8.2, it's less of an issue and so far there are very few that require an alternate PHP version. But it was a significant issue in v17.x because Bullseye had PHP7.4 fairly late in the PHP7.4 lifecycle. Many users needed (or at least wanted) a newer PHP version. That was exacerbated by the fact that many non stable Linux distro users (and also upstream PHP app devs) thought that PHP7.4 was EOL fairly early in the lifetime of Bullseye/v17.x. In fairness it was EOL upstream, but as you'd be aware, Debian provide backported security updates (so the PHP version stays the same, but is secured). Whilst it's not really an issue in v18.0 so far, it may well again become an issue later in the release cycle?

Regardless, your push back has urged me to look a bit closer!

It seems that the other phpX.Y DB packages (i.e. currently php8.2-sqlite3 & php8.2-pgsql) actually provide the corresponding the relevant packages that include the PHP version - via virtual packages - something I had previously missed. E.g. in the case of php8.2-sqlite3 (from the package control file):

Package: php8.2-sqlite3
Source: php8.2
Version: 8.2.7-1~deb12u1
[...]
Provides: php-pdo-sqlite, php-sqlite3, php8.2-pdo-sqlite
[...]

However the php82.mysql package doesn't provide php-mysql?!:

Package: php8.2-mysql
Source: php8.2
Version: 8.2.7-1~deb12u1
[...]
Provides: php-mysqli, php-mysqlnd, php-pdo-mysql, php8.2-mysqli, php8.2-mysqlnd, php8.2-pdo-mysql
[...]

(note the Provides lines)

So apps that use an alternate DB backend, it's not an issue...

I probably should check in with the PHP Debian packaging team to see if it's actually a bug, or whether there is a rationale for that?

Even if it's not considered a bug in Debian for whatever reason and they aren't willing to change that, now I'm thinking about it some more, perhaps just installing the php-mysql package. That would pull in php8.2-mysql in v18.x (weighing in at 447.0 kB). If that was all, it's a no brainer IMO, but I also note that that in turn depends on 'php8.2-common' (weighing in at a more substantial 8,425.0 kB) - for a total installed size of ~9MB (times all our different build types, times however many apps include a non-standard PHP). While that isn't that big a deal (currently) the more apps using a non-standard PHP the more it actually matters. Regardless it's still a better way to go? It would mean that a user who was running PHP8.3 (for example) would have redundant php8.2-mysql & php8.2-common packages, whilst the PHP application(s) itself would be using the php8.3-mysql package for example. Perhaps that's not actually a big enough deal for us to worry about and I'm already over-engineering?

Regardless, I'll open a bug report in Debian re the above note and report back. Regardless, I'd be interested in your thoughts on the potential workaround (i.e. the redundant phpX.Y-mysql & phpX.Y-common package).

As something of an aside, we've had a user contributed script to change PHP version (turnkeylinux/common#291). That will end up with even more redundant and unused packages, but I'm not that concerned when end users do that themselves. It's more the ones we provide...

Sorry for the rambling essay and thanks again for sharing your thoughts.

[JedMeister]

FWIW bug reported to Debian - we'll see how it goes...

[JedMeister]

Debian bug report is here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061469

[JedMeister]

Ok, so as per feedback from my bug report, it turns out that the issue we're working around (by building our php-mysql dummy package) is actually a bug in the adminer packaging. adminer currently depends on php-mysql (or php-sqlite3 or php-pgsql) whereas it should depend on php-mysql | php-mysqli (etc). php-mysqli is a virtual package provided by phpX.Y-mysql - e.g. php8.2-mysql.

With this fixed, we should not need to build the dummy package and changing PHP versions won't be so tricky.

IMO a nice touch would be if we tweaked fab to let it work out which phpX.Y packages to install if PHP_VERSION is set in the Makefile - then we could always have the unversioned PHP packages in the plan. E.g. assuming PHP_VERSION=8.1 - we could just have php-gd in the plan and it would know to install php8.1-gd. But that's outside the scope of this issue and is a wishlist item for another day...

I've renamed the Debian bug report and retargetted it to the Adminer package. I also uploaded a patch to fix it, but I'm not sure whether it will make it into Debian any time soon?

So between this and the new php-updater script (see turnkeylinux/common#291) I may as well close this bug... Thanks again for your input @a3s7p.

In other related news, it appears that Adminer has been abandoned by the upstream dev. It has been forked by a new team and renamed AdminerEvo. The Debian Adminer packager is working on a new AdminerEvo package (see Debian bug #1055329) which hopefully should be ready by the time Debian 13/Trixie is released as stable. I've opened a separate bug noting the Adminer -> AdminerEvo for v19.0 (see #1896).

[JedMeister]

Actually, when closing this issue, I should have also I should have also explicitly mentioned that we now have a tkl-update-php helper script, contributed by @marcos-mendez (see turnkeylinux/common#290 & turnkeylinux/common#291).