buildsupport/php: add passthru.updateScript

Lets make sure that (almost) all PHP packages can be updated by the r-ryantm bot!

PHP packages where upstream provides a lock file can be automatically updated with the standard nix-update-script. The next step (in a following PR) will be to create a script that optionally updates and replaces the local lock file if upstream doesn't provide it.

buildsupport/php: add default passthru.updateScript

Lets make sure that (almost) all PHP packages can be updated by the r-ryantm bot!

PHP packages where upstream provides a lock file can be automatically updated with the standard nix-update-script. The next step (in a following PR) will be to create a script that optionally updates and replaces the local lock file if upstream doesn't provide it.

buildsupport/php: add default passthru.updateScript

Lets make sure that (almost) all PHP packages can be updated by the r-ryantm bot!

PHP packages where upstream provides a lock file can be automatically updated with the standard nix-update-script. The next step (in a following PR) will be to create a script that optionally regenerates and replaces the local lock file if upstream doesn't provide it.

Pol Jan Tojnar sorry for the PR spam...

(yes, I know how git works)

I might be missing something, so I'll just ask here:

The box PHP package is built with php82.buildComposerProject and upstream also has "php": "^8.2" in their composer.json (and .lock). But then why does it also end up in the php81Packages set?

Shouldn't we have some kind of mechanism that uses the php version that composer uses to decide whether or not it belongs in a given package set?

Another question:

isn't it kind of problematic that we supply lock files (with a lock for packages where upstream doesn't provide one) using composerLock = ./composer.lock that is generated with only a single php version, while the package is in 3 package sets (phpPackages 81, 82, 83)? Shouldn't we have 3 different generated lock files, or at least generate the lock file using the lowest supported php package set version? (so 81)

There is a very slight chance, but I'll try anyway ^^

Is anyone aware of the couchbase php sdk going closed source? We have a PHP extension for couchbase that currently doesn't build. We have 3.2.2, which is the last version on the repo. But it seems like the newest version is 4.2.1.

So I'm afraid they went closed source and we'd just have to build from the tarball. But maybe I'm missing something since I don't use couchbase?

In reply to @patka_123:matrix.org

There is a very slight chance, but I'll try anyway ^^

Is anyone aware of the couchbase php sdk going closed source? We have a PHP extension for couchbase that currently doesn't build. We have 3.2.2, which is the last version on the repo. But it seems like the newest version is 4.2.1.

So I'm afraid they went closed source and we'd just have to build from the tarball. But maybe I'm missing something since I don't use couchbase?