Basic guide to write Gentoo Ebuilds

This article Article description::contains instructions for beginners on ebuilds development.

Ebuilds, where do they live? How do I create one?
When you had set up Gentoo, you probably remember that you had to download and unpack a Gentoo repository snapshot. This snapshot (which you later update when you run ) is full of ebuilds, it is the Gentoo repository and once unpacked is usually located at.

Now, you can't just create a file and be done with it; there are several reasons:


 * 1) It is your local copy of the remote Gentoo repository: If you place an ebuild in there or update an ebuild, then you run, your changes will be gone. Therefore, you will want to work in  or in a custom repository instead.
 * 2) The ebuild file is not in the right directory: An ebuild has to be located in the "package name" subdirectory of "category" directory; so, for an ebuild to work you have to place it in a directory like.
 * 3) The ebuild file name has no version listed: Packages have versions, they need to be specified in the file name; therefore we would like to create a file like.

So, let's create us a minimal ebuild; to keep it simple I will assume you run under root privileges, you can always use if you feel like.

We recursively create the directories and into it ($_ recalls the last argument), then we create an ebuild out of the ebuild header which is a necessity if you want it added to the Gentoo repository.

Users of get the basic skeleton automatically (provided by ):

Users of other editors manually copy from the header.txt:

This won't run yet, it requires us to define a minimal amount of variables, so let's add the following code inside the ebuild:

Just two variables? Exactly, it is required that we have a one-line DESCRIPTION of our package, and that we explicitly state that we won't use SLOTs, which is what "0" means.

We can now install the package to the system by running:

This will manifest (create hashes, to avoid corruption), clean any present temporary work directories and (e)merge the ebuild.

Good, you have just made and tested your first ebuild, it doesn't really do much but it's a good start!

Adding more useful variables
If you take a look at you see a skeleton with a lot of documentation, we will be adding some of these variables and functions to our ebuild as we proceed; so, it seems wise to read over this file as we go. Add the following code blocks to our :

More information about the EAPI can be found here.

This is a simple tarball which contains a hello-world shell script which echoes "Hello world!".

Next, we need to specify a license, I hereby tell you I am licensing it under the MIT license so let us specify that.

We already did the SLOT, so we can move on to KEYWORDS. The KEYWORDS variable tells you on which architectures a package works and also tells you whether it is masked (not listed or explicitly listed with -), untested (~) or stable (listed, but with no character in front of it). Since we can't stabilize ourselves (bugs are to be filed for that), the best we can do for now is list all the architectures as untested. All the architectures, because they can all run shell scripts.

The other variables define some more specific things (check them out in ) but we won't need them for now; you also see there are functions, but let us see what the ebuild already does by now.

We see that it first tries to download our file from a mirror, but since it is not on the Gentoo mirrors it will download it from the SRC_URI value that was specified.

Then, when it has the file it can create a manifest, this contains a hash of our ebuild and that downloaded file to ensure integrity such that corruption will yield errors.

Then, the emerge process kicks in, the integrity is first checked. Then, we can see the archive we downloaded is automatically unpacked, this is really useful as we don't have to implement this anymore. We can change this behavior by overriding its function, setting some variables or using eclasses whom define such behavior; but we don't need to do that in this case.

As we read further, we see that it tries to prepare, configure, compile and install. In the prepare phase, patches will typically be applied. In the configure and compile phases, the typical build process is done, by default in runs (a wrapper for ) and  (a wrapper for ) when it finds files to handle; but since we use a shell script, we won't need to adjust these phases.

Now, the last step doesn't look quite right; it doesn't install our file yet...

Telling the ebuild where to install our shell script.
In our development manual we can find a page about the phase functions,  seems useful for what we want to do. If you click on the  link you will see what it does by default for each EAPI as well as some examples. As the default doesn't look good, we'll define our own  function. In our function we will be calling other functions to do installation work for us, an overview for them is install functions.

So, we can proceed by adding the following function to our ebuild:

That call will copy hello-world to a temporary build directory, make it executable; later on it will be checked by Portage and copied to the live file systems.

Let us try again...

Ah, we see ">>> /usr/bin/hello-world", that looks good!

Let us try...

And there we have it, we just installed a package that echoes "Hello world!".

Adding more useful variables
This example is similar to the previous one, however, it was written in C++, it has a Makefile, but it does not have configure. It's the same idea, but the package will be compiled :

The code of the files and the Makefile

The end result of the new ebuild:

A package was created from the directory and uploaded and then we ran the command again:  and we realize that the package is automatically compiled and moved to the `/usr/bin/` directory:

To be continued!
New sections will get added as new examples get produced...

Here are some ideas for more examples if anyone wants to help writing this article:


 * Expand on the hello world ebuild by adding a  function where we will patch the package such that the shell script asks for the user's name and uses it instead of world.
 * Usage of variables like P, PN , PV , and PF to ease the maintenance (assume a new version of the package was released).
 * Installation of optional documentation (via ).
 * Usage of, , and other useful eclasses; in easy to use examples.
 * How to ensure QA, deal with QA warnings and errors and set up FEATURES for more reliable ebuild writing.
 * Explain how to contribute and how to become a developer.

Adding support for user patches to ebuilds
Since EAPI 6, the support for user patches is provided by. This can be done by putting default on top in the src_prepare function:

EAPI versions prior to EAPI 6 should not be used for new ebuilds.

Using the PATCHES array
If you need to apply multiple patches to the source code you can declare an array called  and they will be automatically applied in src_prepare. Here is an example:

External resources

 * Quickstart Ebuild Guide
 * Gentoo Development guide
 * Common Ebuild Writing Mistakes
 * Michał Górny: The ultimate guide to EAPI 7
 * - The ebuild command's man page.
 * - The ebuild file format man page.
 * - To check for QA errors, QA keywords are explained in the last part of.
 * The skel.ebuild