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
• [x] support mostly static glibc
• [x] build bulk php cli
• [x] build bulk php fpm
• [x] build bulk php micro
• [x] build bulk php embed
• [x] build all above with zts
• [x] upload binaries
• [x] create packages (easy with fpm)
• [x] 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.

[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.

[henderkes]

With the shared extensions pull request being finished, I started to work on this here:

https://github.com/static-php/spc-packages

[henderkes]

Current status is that debian and ubuntu (last two versions) are supported for php 8.4.

RHEL 7-10 are supported for php 8.2 to 8.5.

I will add deb/rpm fallback versions for other operating systems to an old common denominator glibc version.

Apk (musl dynamic) is still planned.

[crazywhalecc]

I haven't had much time to look into spc-packages project, but if necessary, I will speed up the implementation of the vendor mode for v3. This seems to be of great help to the expansion of the ecosystem for SPC and related things like packages.

BTW if everything is ready, I will see if it can be hosted on static-php.dev's servers.

[henderkes]

Not yet, still missing support for different php versions on deb packages and apt packages in general.

I don't think we really need vendor mode. An exception for that would be to precompile extensions like php-glfw, where the package could declare the dependency. But these can be compiled by users with PIE.

[crazywhalecc]

I don't think we really need vendor mode

As we have implemented static builds of many libraries, I think there is a way to easily reuse them in some other projects, not just PHP. I personally also have this need. For SPC itself, the main purpose is to implement the skeleton command and composer library mode for future updates.

And for spc-packages, after a quick look, it seems that many commands, steps, and exception handling can be reused in SPC without having to be rewritten. Of course, this requires a better implementation of the vendor mode.