# FAQ

Below you can find common questions and answers.

### Q: How do you uninstall an application and get it to reinstall in the application folder with boxen?

When removing applications make sure to remove the corresponding `/var/db/.puppet_appdmg_installed_application` so that boxen will reinstall it.

### Q: How do you remove Boxen?

Run `script/nuke` from inside the `/opt/boxen/repo` directory.

### Q: How do you upgrade your boxen from the public our-boxen?
Anwser distilled from http://grahamgilbert.com/blog/2014/04/04/updating-boxen/
As Boxen is made by GitHub, updating it is much like updating any other project on there that you’ve made a fork of. First we’re going to add it as a remote repository:

```bash
cd ~/src/our-boxen
git remote add upstream https://github.com/boxen/our-boxen.git
```
Then we’re going to fetch the stuff from the upstream repository:

```bash
git fetch upstream
```

Now we’re going to merge the updated repository with our own:

```bash
git checkout master
git merge upstream/master
```

Now deal with conflicts in (Puppetfile, manifests/site.pp), ignore any diffs in Puppetfile.lock and Gemfile.lock.


```bash
git mergetool
```

The next step is to update your Puppet modules and RubyGems. First delete Puppetfile.lock and Gemfile.lock. Now go back to your trusty Terminal and:

```bash
rm Puppetfile.lock Gemfile.lock
bundle install --no-deployment --without development
bundle exec librarian-puppet install --clean
```


### Q: What's a good approach to merging our-boxen back into my private fork?

One approach is to delete the Gemfile.lock and Puppetfile.lock and run:

    # Regenerates Gemfile.lock and installs new Gems
    bundle install --without development

    # Regenerates Puppetfile.lock and caches tarballs
    bundle exec librarian-puppet install --clean

These will generate the respective lock files suitable for committing. Hope that helps.

### Q: Should you keep the cache of the module and gem in the repository?

We recommend yout to keep the files inside `vendor/cache` and `vendor/puppet/cache` inside
the repository.

It ends up adding a negligible amount of disk space in return for much faster runtimes
for other folks on your team (since they don't have to fetch the tarballs one-by-one
through the GitHub API any time a module version changes).