anchor.diff:  Write your packaging scripts now.
   To get started, study the examples.
   
  -* Begin each script with a `set -e -x` line to aid debugging at compile time.
  -* Write each script to install the software for the package it belongs to,
  -and also invoke any package dependencies.
   * Use your dependency graph to determine which dependencies belong in each
   packaging script.
   
  -### <a id="..."></a> Create packaging specs ###
  +* Begin each script with a `set -e -x` line.
  +This aids debugging at compile time by causing the script to exit immediately if an error occurs.
  +
  +### <a id="..."></a> Update packaging specs ###
   
   Within each package directory is a `spec` file which states:
   
  
positive.code:   ctl.erb: bin/ctl
  
  packages:
  - ardo_web
  
  ~~~
  
  ### <a id="..."></a> Commit ###
  
  You have now created a job skeleton.
  If your release includes several jobs, go back and repeat this process for each one.
  
  This is a good time to commit.
  Be aware that if you followed the recommended practice of using the `--git` option with
  `bosh init release`, the correct `.gitignore` file has been automatically created for you.
  
  ## <a id="..."></a> Make a dependency graph ##
  
  There are two kinds of dependencies in a BOSH release:
  
  * The **runtime dependency**, where a job depends on a package at runtime.
  For example, the `ardo_web` job depends on Ruby.
  * The **compile-time dependency**, where a package depends on another package at compile time.
  For example, Ruby depends on the YAML library.
  
  
negative.code: 
  _add examples inline_
  
  ## <a id="..."></a> Add Blobs ##
  
  When creating a release, you use Git for your source code.
  For example, the `web_ui` and `bg_worker` source is checked into a Git repo.
  
  But your release also uses Ruby and libyaml, which are in the form of binaries
  like tar or gem files, also known as blobs.
  Since Git is not well-suited to dealing with large binaries,
  checking these blobs into Git would be problematic.
  
  You can avoid checking blobs into Git by doing the following:
  
  * For dev releases you direct BOSH to use local copies of blobs.
  
  * When creating a final release, you upload blobs to a blobstore,
  then direct BOSH to obtain the blobs from there.
  
  ### <a id="..."></a> Configure a blobstore  ###
  
  Every release has one `config` directory, where you record the information BOSH needs to
  work with blobstores.
  
  In the `config` directory:
  
  * The `final.yml` file names the blobstore and declares its type, which is either `local`
  or one of several other types that specify blobstore providers.
  
  * The `private.yml` file specifies the path of the blobstore, along with a secret.
  
  `private.yml` contains keys for accessing the blobstore.
  For that reason, `private.yml` is automatically gitignored (assuming you used the `--git`
  option when running `git init release` at the beginning of this tutorial).
  By not checking `private.yml` into Git, BOSH keeps the keys private.
  
  **Note**: A peculiarity of the `local` type blobstore is that the `blobstore_secret`
  line is required, although it is deprecated and its content does not matter.
  There is no `blobstore_secret` line for other types of blobstores.
  
  The `config` directory also contains two files whose content is automatically
  generated: the `blobs.yml` file and the `dev.yml` file.
  
  Adapt the example `final.yml` and `private.yml` files to fit the specifics of your release.
  
  _insert examples_
  
  ### <a id="..."></a> Inform BOSH where blobs are ###
  
  Each package has a `spec` file, which has a `files` block.
  For packages whose content you downloaded from the internet,
  the `files` block lists the binaries you downloaded, along with
  the URLs from which you downloaded them.
  (This assumes that you followed the directions in the [Update package specs] section.)
  
  Those files are blobs, and now you need the paths to the downloaded blobs on
  your local system.
  
  In our example, the `spec` file for the `libyaml_0.1.4` package includes the line:
  
  ~~~yaml
  files:
  - libyaml_0.1.4/yaml-0.1.4.tar.gz # From http://pyyaml.org/download/libyaml/yaml-0.1.4.tar.gz
  ~~~
  
  If you downloaded the blob, its local path might be:
  
  `~Downloads/yaml-0.1.4.tar.gz`
  
  Go through all your packages and make a list of local paths to the blobs you downloaded.
  Now you are ready to inform BOSH about these blobs.
  
  For each blob, run:
  
  `bosh add blob <path_to_blob_on_local_system> <package_name>`
  
  ### <a id="..."></a> Do not upload blobs for a dev release ###
  
  The nature of blobstores (other than local ones) is that once you have uploaded blobs,
  those blobs may become essential to some other developer.
  For this reason, uploading a blob and then removing it is considered poor practice.
  
  When creating dev releases, you should run `bosh add blob` to inform
  BOSH of local paths to blobs, but refrain from running `bosh upload blob`.
  That command is discussed in connection with dev releases.
  
  ## <a id="..."></a> Update Specs to Complete Jobs ##
  
  _what have we not done yet?_
  
  ## <a id="..."></a> Create Release Properties  ##
  
  * Properties are inputs ...
  * Coordinating with the `properties` block in the manifest...
  