orpiske commented on pull request #2141: URL: https://github.com/apache/camel-k/pull/2141#issuecomment-801035102
> My understanding is that the Kamel binary added to the operator image should be built on the image OS. I think that the current approach, that is to build the `kamel` binary locally, and add it to the operator image, is either an heritage of how the operator SDK scaffolded the project at its creation, or a convenient way to re-use the binary that is also used for the client CLI. We already cross-compiled the binary, which deactivates CGO, when it's built on non Linux OS. > > It seems a possible solution would be to refactor the Dockerfile, and use a build stage to compile the binary on the same OS as the final image. Compiling it on the same image could solve the problem, indeed. However there's one thing that concerns me with this approach: it makes it harder for distribution packagers and downstream users building and productizing this. This is specially true on environments with secluded internet access, where the dependencies may not be available at build time. Thus forcing the users/packagers to go through the work of copying previously cached dependencies into the build stage and dealing with all the downsides of doing that. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
