On 11/10/15, 9:25 PM, "[email protected] on behalf of Jack Perdue" <[email protected] on behalf of [email protected]> wrote:
>On 11/10/2015 11:05 PM, Kenneth Hoste wrote: >> On 11/11/15 04:27, Christopher Samuel wrote: >>> On 11/11/15 07:06, Kenneth Hoste wrote: >>> >>>> Besides the things mentioned by Alan below, to have a truly >>>> reproducible >>>> setup, EasyBuild should be combined with Nix (see >>>> https://nixos.org/nix/), in order to be in full control of the build >>>> environment. >>> ...and perhaps some form of containerisation to package up an >>> environment so that changes to underlying system libraries don't affect >>> you either (though kernel & CPU microcode changes will still mean >>> differences). >> >> afaik, Nix also covers that, but I have to admit I haven't played >> around with it myself (yet). > >I'm not sure if mock/koji aid in this or work against it. > >mock does a great job of providing a clean build environment (for RPMs.... >though I could see it being used for EB as well in a weird twisted way). > >I've always (well, for 10+ years) been in the camp that I want changes >in underlying system libraries (e.g. security updates) to affect, by >default, >my binaries. OpenSSL updates are a good thing. In Spack, we're working on a feature where you could simply upgrade offending libraries for all packages that use them. Since we RPATH everything, and everything is in its own prefix, it's a matter of building the new version, and symlinking the old directory location to the new install. This would update libs like OpenSSL for all packages using them. It would also let you track what version the original package was installed with, since the RPATHs still effectively point at that location. We've thought about both the dynamic and static case for this -- for the dynamic case you could do what I described above; for the static case you'd need to rebuild everything that depends on the offending library. -Todd
