update docs for rpm packages and extension availability

[henderkes]

continues #1756

[dunglas]

Do you think we could create CNAME to use frankenphp.dev subdomains?

Also, maybe could we update the installation script to install the packages if possible?

[henderkes]

We could. I have cloudflare in front of public access, which wouldn't work without an enterprise plan, but I wouldn't mind sending you the IP (or I could sync the packages to some web storage you already have?). We can talk about it in person next week.

I've considered making the packages the default in the installation script, but we would need to inform users that not all the default extensions will be installed by default. Or should we install them and let users uninstall what they don't need?

[dunglas]

Just adding CNAMEs on my side should work. I'll try.

IMHO just installing the packages and printing a message saying that it's possible to install extra extensions (with maybe a link to the list) is good enough.

[dunglas]

I created CNAMEs for deb.frankenphp.dev, rpm.frankenphp.dev and key.frankenphp.dev, but as you also package many other PHP-related software, we may also just use the current domain if you prefer.

[henderkes]

I'm fine with frankenphp.dev, but the repo file (static-php-1.0.rpm) will have to be adjusted, otherwise the packages themselves will still be downloaded via rpm.henderkes.com.

https://github.com/static-php/spc-packages/blob/master/config/static-php.repo

I can create a new rpm package called frankenphp-repo-1-0.rpm? But that would be confusing for future updates to the repo.

[henderkes]

After thinking about it for a while, I think we have three options:

• mirror the rpm repo using reposync (and whatever there is for .deb)
• keep the existing domain
• move everything over

I think the redirect and conflicting support info (signed in the packages) is too confusing otherwise.

I'm generally open to all three options, but plan to add other packages in the future, too. Might be a bit strange to see pasir and rust extensions distributed under frankenphp.dev 😅

[dunglas]

Option 2 looks the best option to me.
Maybe shout we just adapt the wording a bit to say that we recommend using packages you provide instead of "we offer packages"?

[henderkes]

I'm kind of doing it in my capacity as a frankenphp maintainer (or at least the lack of availability outside of Docker was the main incentive) and don't really care about the credit part, but I agree that it's a bit confusing.

I'll sleep it over. I recall there's some mirror configuration in rpms, so we might get away with frankenphp.dev primary domain, fallback to my domain.

[henderkes]

@dunglas since the gpg key used also prints my information when installing, I guess the only way to avoid ambiguity is to say it explicitly. I'll leave the wording up to you.

[henderkes]

I don't feel comfortable mentioning my name explicitly in three places. Maybe just "Our maintainer offers..." or accept the ambiguity and say "We"?

[henderkes]

Which one should we use in both places? I think both are fine, or even keep it like this.

@alexandre-daubois this would close #1753 as there's no point having non-updating packages when proper versions are available.

Adding apk packages is also still on my agenda, but if you'd like to add it at https://github.com/static-php/spc-packages (just need a createApkPackageWithFpm method with correct dependency naming and call the workflow with --target="native-native-musl -dynamic") you're more than welcome to 😅.

[henderkes]

Should be good to merge now. As a side bonus, we now have -debuginfo packages so users can get useful stack traces more easily and we use the green tea gc, which should hopefully give us a few extra percent performance in webserver-heavy workloads.

[dunglas]

LGTM, I would just like to fix the macOS build issue before merging (in case we should temporarily revert #1968, see #2007).

[henderkes]

Jerry is working on it at crazywhalecc/static-php-cli#970, but of course it builds fine in our CI...

[henderkes]

Looks like it also builds fine from FrankenPHP source for him locally #2002 (comment). Might just be an issue with the CI runner here?

[crazywhalecc]

I've tested on my macos-14 hackintosh, and this CI is using macos-13 which is deprecated. I'll try installing macos-13 vm later.

[henderkes]

Huh, I thought we updated to macos-15-intel!

[dunglas]

Thanks!