# What is `buildpack-deps`?

In spirit, `buildpack-deps` is similar to [Heroku's stack
images](https://github.com/heroku/stack-images/blob/master/bin/cedar.sh). It
includes a large number of "development header" packages needed by various
things like Ruby Gems, PyPI modules, etc. For example, `buildpack-deps` would
let you do a `bundle install` in an arbitrary application directory without
knowing beforehand that `ssl.h` is required to build a dependent module.

%%LOGO%%

# How to use this image

This stack is designed to be the foundation of a language-stack image.

# What is `buildpack-deps`?

In spirit, `buildpack-deps` is similar to [Heroku's stack
images](https://github.com/heroku/stack-images/blob/master/bin/cedar.sh). It
includes a large number of "development header" packages needed by various
things like Ruby Gems, PyPI modules, etc. For example, `buildpack-deps` would
let you do a `bundle install` in an arbitrary application directory without
knowing beforehand that `ssl.h` is required to build a dependent module.

%%LOGO%%

# How to use this image

This stack is designed to be the foundation of a language-stack image.

## What's included?

The main tags of this image are the full batteries-included approach.  With
them, a majority of arbitrary `gem install` / `npm install` / `pip install`
should be successfull without additional header/development packages.

For some language stacks, that doesn't make sense, particularly if linking to
arbitrary external C libraries is much less common (as in Go and Java, for
example), which is where these other smaller variants can come in handy.

### `curl`

This variant includes just the `curl`, `wget`, and `ca-certificates` packages.
This is perfect for cases like the Java JRE, where downloading JARs is very
common and necessary, but checking out code isn't.

### `scm`

This variant is based on `curl`, but also adds various source control management
tools.  As of this writing, the current list of included tools is `bzr`, `git`,
`hg`, and `svn`.  Intentionally missing is `cvs` due to the dwindling relevance
it has (sorry CVS).  This image is perfect for cases like the Java JDK, where
downloading JARs is very common (hence the `curl` base still), but checking out
code also becomes more common as well (compared to the JRE).

Add some documentation about where the line between the new variants of buildpack-deps is
Add some documentation about where the line between the new variants of buildpack-deps is
