Idea: creating mostly static package repos

[henderkes]

I.e. link everything except libc statically, that way both musl and glibc can load shared extensions. Build php with all extensions. Then package it and offer a repo url like https://apk.static-php.dev, https://deb.static-php.dev and https://rpm.static-php.dev

Installing one of those with apk, apt or dnf would then enable users to dnf install static-php-zts to install static php-cli, php-fpm, php-embed. Then a few weeks later dnf upgrade to upgrade to static-php-zts-8.4.8-1.rpm.

I've looked into it and it shouldn't require too much work. Mostly just static hosting space. Our github actions could build the packages like static-php-8.4.7-1.arm64.rpm and would upload them into the webspace. Then each day the webspace could sign them with a gpg key and regenerate repository information.

For the question why to do this: convenience. We also currently offer the only reliable source of zts support across all operating systems and architectures (windows aside).

We are already 95% of the way
there, anyhow. https://dl.static-php.dev/static-php-cli/bulk/

• support mostly static musl
• support mostly static glibc
• build bulk php cli
• build bulk php fpm
• build bulk php micro
• build bulk php embed
• build all above with zts
• upload binaries
• create packages (easy with fpm)
• create package registry

[henderkes]

I'm not saying we should do this, by the way. Just documenting a consideration I currently have and I'd like to get your feedback on it, because it does shoot a little far from the projects original philosophy.

[wheakerd]

那为什么不是项目去兼容这个功能呢？项目的运行需要构建出一个可执行文件？就像 rust 语言开发出的 Actix-web 框架一样？

[henderkes]

Sorry, I'm not sure if I understand your question. Static php cli builds php executables: cli, fpm, micro and embed (either static or as a shared library).

This issue is about creating packages to allow users to install and update static-php-cli generated static php binaries with their system package managers.

[crazywhalecc]

I still have a few questions:

1. The bulk combination is not containing all supported extension. Some extensions are conflict with each other like swow and swoole. That means we cannot publish Build php with all extensions, we can only publish like bulk, but if possible, we can select default extensions through the community or other statistical methods.
2. The build package sounds like it has little to do with static-php-cli itself, it should be similar to another static-php-cli-hosted project.
3. The ZTS release suggestion sounds great to me, maybe we could release a zts-bulk package (at this point)?
4. Regarding package management, I am not sure whether it is necessary, but if we consider the sustainability of the project in the future, it may be necessary.

However, considering the development of the static-php-cli project, I feel that static-php-cli itself is more like a package manager (although it does not really manage packages, but only builds packages).

My original expectation is that static-php-cli can also build static executables other than PHP, because the dependencies are reusable, but they should also be in the ecosystem around PHP and C/C++.

🫨 My expression is more random, but if you want a simple feedback, my answer is: I am open to it.

[henderkes]

Yeah number 1 is the point I am most unsure about. Optimally we would mimick the behaviour of existing package repositories as much as possible, meaning we'd build spc-min statically and all other extensions dynamically. But that would be more work and maintenance than a single run of fpm to build a package.

Points number 2 and 3 I agree. 4 I think is not necessarily for developers around the extension/compilation landscape, but for regular php users.

I think it's an important point in the direction of becoming a widely used, convenient option of installing up-to-date php without 28181 dependencies.

I will throw up a repository on static-php organisation to build up a repo on my server. We can switch to static-php.dev before publishing then.