I really want to look at making this a first class build path in OpenShift - it has a ton of advantages for builds of base images, and enables admins to slice and dice their toolchains. The question that has held it up so far is what API surface does it need - maybe make s2i capable of leveraging the concepts
On Feb 11, 2016, at 4:54 PM, Colin Walters <walt...@verbum.org> wrote: On Thu, Feb 11, 2016, at 05:08 AM, Daniel Riek wrote: * Enable mounting containers as volumes (unless I am mistaken, right now we can only mount host directories as volumes? Might be wrong) This is: https://github.com/docker/docker/issues/7115 The thing that gets really messy is, sure you can mount another container with dnf or whatever at /build/dnf, but everything that is used as part of a build needs to be effectively statically linked. Or alternatively, compute a union of files in /usr/bin. But then you have to look for *new files* that the build may have dropped in /usr/bin, while still deleting files from the union from the build. The rpm-ostree container approach to this is that builds always output rpms, except it runs as non-root, (and we can make that *much* faster than a simple aggregation of yum install + docker) but it also supports aggregating them into final images.
