Custom repository

Important
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:

root #emerge --ask app-portage/repoman

Creating a local repository

See Handbook:AMD64/Portage/CustomTree#Defining a custom repository

Adding an ebuild to the repository

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

root #mkdir -p /usr/local/portage/app-dicts/artha

root #cp ~larry/artha-1.0.2.ebuild /usr/local/portage/app-dicts/artha/artha-1.0.2.ebuild

root #chown -R portage:portage /usr/local/portage

root #pushd /usr/local/portage/app-dicts/artha

root #repoman manifest

root #popd

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

root #emerge --ask --verbose app-dicts/artha

If you're doing this often, you might consider using a bash script to semi-automate the process, such as:

FILE repoAdd.shAutomated example

#!/bin/sh
mkdir -p /usr/local/portage/$1/$2
cp $3 /usr/local/portage/$1/$2/
chown -R portage:portage /usr/local/portage
pushd /usr/local/portage/$1/$2
repoman manifest
popd

For the above app-dicts/artha ebuild example, presuming the script is named repoAdd.sh, the command would be:

root #repoAdd app-dicts artha ~larry/artha-1.0.2.ebuild

With the syntax (<package_category> <package_name> <ebuild>)

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
• 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 bobs-repository already and want to bump to a newer version of app-emulation/docker.

user $mkdir -v /usr/local/portage/bobs-repository/app-emulation

user $cd /usr/local/portage/bobs-repository/app-emulation

user $cp -r /usr/portage/app-emulation/docker .

user $cd docker/

user $cp docker-1.11.0.ebuild docker-1.12.6.ebuild

user $repoman --digest=y -d full

Now test the installation:

root #emerge --ask =app-emulation/docker-1.12.6

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

Avoid a direct version bump

The direct version bump in the official ebuild repository is often suggested, but should be avoided, because:

• All changes get lost on the next sync of the repository (unless sync-type git is in use, in that case a topic branch could be used)
• User contributions should be separated from the official ebuild repository

Do not do this:

root # # cd /usr/portage/app-emulation/docker

root # # cp docker-1.11.0 docker-1.12.6

root # # repoman --digest=y -d full

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 /usr/local/portage). The best solution is to create an overlay specifically for crossdev's use:

root #mkdir -p /usr/local/portage-crossdev/{profiles,metadata}

root #echo 'crossdev' > /usr/local/portage-crossdev/profiles/repo_name

root #echo 'masters = gentoo' > /usr/local/portage-crossdev/metadata/layout.conf

root #chown -R portage:portage /usr/local/portage-crossdev

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:

FILE /usr/local/portage-crossdev/metadata/layout.conf

masters = gentoo
thin-manifests = true

Then instruct Portage and crossdev to use this overlay:

FILE /etc/portage/repos.conf/crossdev.conf

[crossdev]
location = /usr/local/portage-crossdev
priority = 10
masters = gentoo
auto-sync = no

See also

• See Defining a custom repository (amd64 handbook)
• Gentoo GitHub - Use a git branch for development and testing of ebuilds