Re: [atomic-devel] 3 kinds of "docker build"

[Colin Walters <walters verbum org>]

On Thu, Oct 16, 2014, at 10:31 AM, Clayton Coleman wrote:
> 
> I think the big question is whether that's the common use case. 

By number of potential users of Docker containers?  I don't know.

But I think real-world important apps like OpenStack are going
to end up needing something of this form.

> Part of
> why STI exists is that the vast majority of software intended for web
> deployment (directly, vs as libraries) has no real need for RPM other
> than as a mechanism to verify the exact version deployed.  

Right, I wouldn't disagree.

> The input build image is the build-requires.

The web world is also dominated by dynamic scripting languages, where
for the most part, you don't really *have* a build process - you're just
copying
your script files into a target, running them out of "git clone" or
whatever.

For static languages like C/C++/Rust, and to a lesser degree Java[1],
there's a large difference between build and runtime dependencies.  Go
is static but a different beast because it only supports static linking,
so it's already embedding its runtime dependencies.

But as an author of C apps (or more interesting, hybrid C/script apps),
I don't want to carry gcc in my containers.

I'd be hopeful that the same backend tool could flow gracefully
up in complexity when you need more out of it.  That may be very
optimistic though...

We've had this discussion before, but I'm hopeful that there are now
more people in the project that are able to take a look at this.

For example, mock recently learned LVM:
http://miroslav.suchy.cz/blog/archives/2014/10/12/big_changes_in_mock/index.html
and IMO it would have made more sense to look at using Docker for
compilation of RPM artifacts.
I'll see if I can get some of those people onto this list.

[1] Yes there's JDK versus JRE, but the Wildfly image just tosses in the
JDK, and I doubt anyone cares about the space difference