Custom ebuild repository

Creating a local repository

See Defining a custom ebuild repository in the Handbook. (Obviously, before a custom repository could pick up ebuilds it needs to exist.)

Optional: Use version history

In order to keep track of all changes done in the custom repository it appears useful to have dev-vcs/git installed. To log all edits from the beginning following steps were needed:

Initialized empty Git repository in /var/db/repos/localrepo/.git/

This also provides the possibility for testing with different version branches.

Adding an ebuild to the repository

Now that the basic layout is in order, an ebuild could be added to the repository. In this example, app-dicts/artha-1.0.2 (available at ). Assumed the ebuild is in the homedir of the user larry, and named artha-1.0.2.ebuild.

It should now be possible to install the package from the ebuild repository with the emerge command:

Simple version bump of an ebuild in the local repository

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 ^[1]
• The ebuild file is short and does not use many patches

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

We assume you have prepared your local repository in localrepo already and want to bump to a newer version of app-emulation/docker.

Now test the installation:

Finished ebuilds should be added to the version control system. If using git, consider adding a pull request to GitHub.

Crossdev

sys-devel/crossdev will place the ebuilds/categories it generates into one of four places in this order.

1. An overlay specified on the command-line with the --ov-output (-oO) option
2. An overlay named 'cross-${CTARGET}'
3. An overlay named 'crossdev'
4. Finally, it falls back on the overlay having the lowest priority value in /etc/portage/repos.conf/.

If the overlays have the same priority, it will use the overlay determined to be the first, alphabetically.

Most users will want to prevent crossdev from disturbing layman's overlays or the user's personal per-machine overlay (commonly created at /var/db/repos/localrepo/). 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:

<syntaxhighlight lang="ini">masters = gentoo
thin-manifests = true</syntaxhighlight>

Then instruct Portage and crossdev to use this overlay:

<syntaxhighlight lang="ini">[crossdev]
location = /var/db/repos/localrepo-crossdev
priority = 10
masters = gentoo
auto-sync = no</syntaxhighlight>

Historical

Older versions of sys-apps/portage included repoman. Starting from portage-2.3.0, repoman has been 'unbundled' into separate package. Be sure it is installed before following this guide:

Alternatively, the ebuild command can still be used to generate manifest/digest files, however it does not include any of the other quality check benefits (such as debug output) included with repoman:

>>> Creating Manifest for /usr/local/portage/bar/foo

See also

• See Defining a custom repository (amd64 handbook)
• Repository format — A quick reference to Gentoo ebuild repository (overlay) format.
• GitHub Pull Requests

References