"lwthiker/curl-impersonate:0.5.1-ff" is built using Alpine, not Debian about curl-impersonate HOT 4 CLOSED

There are now Debian-based images on Docker Hub as well.
Please note that the previous tags still point to the Alpine Linux images. The Debian tags are suffixed with -slim-buster, e.g.:
0.5.2-chrome-slim-buster, 0.5.2-ff-slim-buster

from curl-impersonate.

The Docker images on Docker Hub are intentionally Alpine-based to reduce the size to a minimum.
It is also explicitly stated in the README file:

Docker images based on Alpine Linux with curl-impersonate compiled and ready to use are available on Docker Hub.

Is there a need in your project for Debian-based Docker images on Docker Hub as well?
You could also use the pre-compiled binaries which might be simpler.

from curl-impersonate.

The Docker images on Docker Hub are intentionally Alpine-based to reduce the size to a minimum. It is also explicitly stated in the README file:

Docker images based on Alpine Linux with curl-impersonate compiled and ready to use are available on Docker Hub.

OK, but in this case the tags on Docker Hub are kinda misleading, as you publish 0.5-ff-alpine alongside 0.5-ff, both of which are the same, whereas one could assume the latter is actually debian (like I did).

Is there a need in your project for Debian-based Docker images on Docker Hub as well? You could also use the pre-compiled binaries which might be simpler.

Indeed, they are useful for docker multi-stage builds, where other stage (or stages) use Debian-based images as well.

Have a look at this particular case I am working on: RSS-Bridge/rss-bridge#2941.

Alpine uses musl in place of libc, so after copying the binaries/libs over to the Debian-based image, they fail to run. I could apt add musl in debian image, but that in turn requires additional symlinking to match the musl.so originally linked against (which musl debian package doesn't do), which, as you can guess, quickly becomes rather dirty/hacky and an additional maintenance burden, e.g. for when musl.so symlink gets updated. EDIT: not even sure if that would work, i.e. to have libraries compiled against different C stdlibs loaded by the same process...

The multi-staging build appears to me be the easiest and cleanest way to replace curl with curl-impersonate in any image, since it can take care of matching the architectures automatically. Actually downloading your pre-compiled binaries into the image is not easier IMHO, as it requires handling that very aspect by hand — which BTW wouldn't be possible now, anyway, since you also don't publish them for arm. my bad, I see that you do offer arm64 binaries.

from curl-impersonate.

Thank you, much appreciated!

from curl-impersonate.