Creating an ebuild repository

A local overlay is useful to
 * install an ebuild you got from some one
 * develop your own ebuilds

Creating a local overlay
A local repository (aka local overlay) can be set up with a few steps creating the mandatory elements of the repository format.

Next, tell Portage about the overlay:

Adding an ebuild to the overlay
Now that the basic layout is in order, you can add an ebuild to the overlay. In this example, app-dicts/artha-1.0.2 (available at ). We will assume the ebuild is in the homedir of the user, and named.

You should now be able to install the package from your overlay with emerge.

Simple version bump of an ebuild in the local overlay
In theory one can update an ebuild to the next version number with a "simple version bump". Indicators that this is promising are:
 * upstream fixed only minor bugs
 * dependencies did not change
 * upstream uses semantic version numbers and changed only the minor number
 * the ebuild file is short and does not use many patches

For the simplest bump place a copy of the ebuild in your local overlay and update the version number in the filename.

We assume you have prepared your local overlay in bobs-overlay already and want to bump from app-emulation/docker-1.11.0 to app-emulation/docker-1.11.2

now test the installation

you may add it to your version controll system. If you use git:

Crossdev
crossdev will automatically place the ebuilds/categories it generates into the highest priority overlay found in. In order to do this you must set the priority number to something low. Most users will want to prevent crossdev from disturbing layman's overlays or the user's personal per-machine overlay (normally created at ). The best solution is to create an overlay specifically for crossdev's use:

If the main Portage tree is synchronized by using Git, or any other method with Manifest files that do not include checksums for ebuilds, prevent "masked by: corruption" errors with:

Then instruct Portage and crossdev to use this overlay: