Isolated environment is hard-coded for building bosh-releases
Opened this issue · 4 comments
The bosh-cli sometimes compiles releases, e.g. for bosh create-env. It therefore requires compilation tools that may need certain environment-variables, e.g. to find dynamically linked libraries and header-files.
installation/pkg/compiler.go:95-108 prohibits the propagation of needed environment-variables that are intended to solve this. One examle is LIBRARY_PATH which is like the (already propagated) LD_LIBRARY_PATH but relevant for compilation-time instead of run-time. But there are quiet some more.
For me it would be sufficient, to switch off the UseIsolatedEnv e.g. via a cli-flag. Then the caller is responsible for providing a correct and clean environment.
bosh releases should be self-contained and should bring the needed header-files / libraries. For example, the ruby release bring libyaml: https://github.com/cloudfoundry/bosh-package-ruby-release/blob/main/packages/ruby-3.3/packaging#L55
In case of using isolated environments, bosh could use a docker-image that provides everything it needs for its release-compilations. This would be then truly-isolated and reproducible at least on all systems that provide a running docker-demon.
We do provide stemcells as docker images, so those might be a good option for running a create-env from: https://github.com/cloudfoundry/bosh-linux-stemcell-builder/pkgs/container/ubuntu-jammy-stemcell
We do provide stemcells as docker images, so those might be a good option for running a create-env from: https://github.com/cloudfoundry/bosh-linux-stemcell-builder/pkgs/container/ubuntu-jammy-stemcell
@jpalermo Hm we already run bosh cli in a container image, the base layer is not ubuntu though. However its a normal linux derivate with all the neccecary and documented system environment variables set according to docs for e.g. GCC or LD to work properly. They way bosh cli is written is not OS agnostic it makes hard assumtions here that it runs a debian based OS.
So while running in a stemmcell would defenetely work somehow it means the community would state that the Bosh CLI is just supposed to work there and neither on macos, openbsd nor orther linux derivates as it wants to keep assumtions over the OS hard coded instead of using the interface described by the used tools properly.(GCC/LD).
The point here is if we call GCC we should call it as documented https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html and not just assume a certain derectory for libs that is just true for some linux/unix derivates. Thats why the GCC guys introduced LIBRARY_PATH in the first place presumably. : )