Missing packages for x86_64

[jensscherbl]

What happened?

@henderkes Hope this is the right place for the issue. There seems to be a problem with the packages targeting x86_64 or linux/amd64 architecture sometimes. I first noticed this for the php-zts-embed (8.4.21-1) Debian package, which is already fixed with 8.4.22-1 now.

• https://pkg.henderkes.com/84/-/packages/debian/php-zts-embed/8.4.21-1

But now I’m seeing the same issue with other new packages as well.

• https://pkg.henderkes.com/83/-/packages/alpine/frankenphp/1.12.4p83-r0
• https://pkg.henderkes.com/84/-/packages/alpine/frankenphp/1.12.4p84-r0
• https://pkg.henderkes.com/85/-/packages/alpine/frankenphp/1.12.4p85-r0
• https://pkg.henderkes.com/85/-/packages/debian/frankenphp/1.12.4+php85-1

Any ideas?

Build Type

apk packages

Worker Mode

No

Operating System

GNU/Linux

CPU Architecture

x86_64

PHP configuration

phpinfo() output

Not relevant here.

Relevant log output

Relevant log output

[henderkes]

What's the issue? 8.4.22 only released today alongside 5 other packages, two of which fail to build from source, so it's not out for all platforms yet.

[jensscherbl]

What's the issue?

Issue is that my builds are failing at the moment because my workflow always tries to build images for both linux/amd64 and linux/arm64. If I understand you correctly, might be a problem with my workflow being based on wrong assumptions, though.

See https://github.com/kenshodigital/frankenphp/actions/runs/27020857489

8.4.22 only released today alongside 5 other packages, two of which fail to build from source, so it's not out for all platforms yet.

So it’s expected that package versions are not always available for all platforms? Nevermind then, I thought there was some sort of hiccup in the build process for the packages maybe.

Still, I’m kinda wondering what would be a good approach for the container images in such a case. Having specific releases randomly not being available on one platform or the other might be a bit confusing. Any recommendations?

[henderkes]

So it’s expected that package versions are not always available for all platforms?

Yes. For one, arm gcc runners are ~2.5h faster than x86_64 zig runners. Second, there aren't enough runner slots to build all at once. And third, when some packages fail to build from source, I need to manually intervene. Today it was gmssl (v1.1.1 references symbols that don't exist in the latest library release) and fastchart on x86_64 (relocation failure). I'll fix it tomorrow.

You can't rely on everything releasing at once from other packagers either. The correct approach would be building whatever is available at the time.

You can actually completely skip building new images on every frankenphp release. A apt upgrade would already do the trick. System packages pin versions themselves. The vast majority of users need some extensions and everything including frankenphp is already prebuilt, the Docker images aren't doing anything but saving users 0.5 seconds when they download them rather than distroless + frankenphp.

[jensscherbl]

You can't rely on everything releasing at once from other packagers either. The correct approach would be building whatever is available at the time.

Thanks, will adapt my workflow accordingly then.

You can actually completely skip building new images on every frankenphp release. A apt upgrade would already do the trick.

Hardened images don’t have a package manager at runtime, though. As mentioned here, this is more like a proof-of-concept within the constraints of the DHI definition format and build process. At the end of the day, it’s really just that, distroless + frankenphp.

[henderkes]

You could go the build-from-source route with your images: https://frankenphp.dev/docs/docker/#hardening-images

The problem is just that a base image with nearly zero extensions is rarely useful. I've never used a single php project that didn't require at least a few extra extensions:

• composer needs phar, openssl, zip or unzip
• phpbench needs zip, xml (optionally gd)
• wordpress needs a ton
• symfony needs iconv, mbstring, ctype
• any file upload software needs fileinfo/exif
• any image generation software suggests imagick for better quality
• any money handling software requires decimal or bcmath
• etc.

[jensscherbl]

You could go the build-from-source route with your images

Already tried that and it works pretty well with the new StaticPHP alpha. Resulting images are basically DHI static base + frankenphp and about half the size of the package based images.

https://gist.github.com/jensscherbl/edf6907615c38ef1416fe404ac56a124

Problem is that it’s getting killed by GitHub Actions all the time, so I need to optimize the workflow first.

The problem is just that a base image with nearly zero extensions is rarely useful.

Agreed. My idea would be that people could simply modify the extension list in the definition build step and very easily build their own custom images that way, while still using the same build process and follow the same standards than other Docker Hardened Images. At least that’s the plan for my own projects.

[henderkes]

I wasn't suggesting using static-php yourself, but literally following our documentation for distroless/hardened images here: https://frankenphp.dev/docs/docker/#hardening-images

[jensscherbl]

I wasn't suggesting using static-php yourself, but literally following our documentation for distroless/hardened images here: https://frankenphp.dev/docs/docker/#hardening-images

Yup, that’s basically what I’m doing here.

I think I’ve actually tried all the different ways for building and using FrankenPHP by now.

The DHI base images are a bit misleading, though. These include more packages by default compared to using the actual DHI definition format and build process directly, so for my FrankenPHP Docker Hardened Images, I’m actually replicating the “Static (Debian, with glibc)” and “Static (Alpine)” configurations.