Provide binaries compatible with $(uname -m)

[fauust]

Hi!
gosu is not available as package on some distribution, RHEL7/8 for instance.

Would you consider providing the binary in a compatible way with uname -m, or maybe provide an example on how to pull the binary on non-debian OS (where dpkg is not available)?

For instance dumb-init project that is widely used in Docker context provide them with a different naming and the following works and is pretty standard on Linux to determine architecture:
curl -sL "https://github.com/Yelp/dumb-init/releases/download/v1.2.5/dumb-init_1.2.5_$(uname -m)" >/usr/local/bin/dumb-init

Of course this should be a non-breaking change for people already relaying on the actual naming, I am not sure if GitHub provide something for that. So maybe documenting somewhere how to pull it form GH on non-debian OS is a good first step.

Cheers!

[fauust]

Note that for ppc64le it's already ok (and maybe for other arch). Problem concerns amd64 and arm64 so far.

[yosifkit]

Just make a case statement in your Dockerfile to translate uname output into the dkpg value? Similar to how the golang images translate the dpkg architecture to the provided upstream files (https://github.com/docker-library/golang/blob/master/1.17/bullseye/Dockerfile#L26-L60).

---

Using uname -m or arch for platform detection is not always reliable, as it gets the host kernel's architecture, when what you really need to get was the image's userspace architecture. If you are building an arm32v7 image on an arm64v8 host using the proper setarch, you will get armv8l instead of the correct armv6l value (uncertain on the exact values here). See docker-library/official-images#10907 (comment) for more info.

[fauust]

Just make a case statement in your Dockerfile to translate uname output into the dkpg value? Similar to how the golang images translate the dpkg architecture to the provided upstream files (https://github.com/docker-library/golang/blob/master/1.17/bullseye/Dockerfile#L26-L60).

Yes, this is what I end up doing. But it seems still a lot of code duplication to me since I am not using any templating system for my Dockerfiles (maybe I should consider it though).

Using uname -m or arch for platform detection is not always reliable, as it gets the host kernel's architecture, when what you really need to get was the image's userspace architecture. If you are building an arm32v7 image on an arm64v8 host using the proper setarch, you will get armv8l instead of the correct armv6l value (uncertain on the exact values here). See docker-library/official-images#10907 (comment) for more info.

Interesting, thank you! I guess I should try to find a rhel alternative to dpkg --print-architecture then.