This section contains information on the common mistakes developers make when writing ebuilds.
static use-flagstatic use-flag should only be used to make a binary use static
linking instead of dynamic linking. It should not be used to make a library
install static libraries. Instead, the static-libs use-flag is used for this.
ROOT
The usage of ROOT is only designed to influence the way the package is
installed (ie. into ROOT) - building and compiling should not depend on
ROOT. As a consequence of this the usage of ROOT in src_*
functions is not allowed.
See also ROOT.
PORTAGE_COMPRESS comes into play. The file could be
compressed with gzip, bzip2, or some other random compression tool. So,
instead of doing this:
elog "They are listed in /usr/share/doc/${PF}/INSTALL.gz"
Do something like:
elog "They are listed in the INSTALL file in /usr/share/doc/${PF}"
There are several ways to fix non-verbose build logs depending on the build system:
For cmake based build systems it should be sufficient that the ebuild calls
cmake-utils_src_compile which picks up the cmake-utils.eclass variable 'CMAKE_VERBOSE=1'
by default. If you call emake directly for whatever reason, you can do 'emake VERBOSE=1'
(note that cmake-utils_src_compile takes arguments as well which are passed to make).
For autotools based build systems you can pass '--disable-silent-rules' to econf,
or use EAPI 5 where that argument is passed automatically. 'emake V=1' should also work.
For custom Makefiles you often have to write a patch. Try to get upstream to include an option like 'V=1' to enable full verbosity.
Rationale
This flag is not recommended for releases and should always be disabled when encountered in build-logs, because there are numerous cases where this breaks without purpose, e.g.:How to fix
To fix the affected build system you should try the following methods:Specific -Werror=... flags
GCC can turn any specific warning into an error. A specific -Werror flag would be "-Werror=implicit-function-declaration" for example and will only affect warnings about implicit function declarations. It's mostly safe to leave these untouched, cause they are pinned to this issue and should not cause random build time breakage. Also, we can expect that upstream did this on purpose to avoid known runtime errors and not just for testing their builds. However you should check the specified warnings yourself or ask other developers if unsure.Exceptions
Removing "-Werror" from configure.ac can cause breakage in very rare cases where the configure phase relies on the exit code. See app-emulation/open-vm-tools bug. But even then we remove it from the resulting Makefile.
When you submit your ebuilds, the header should be exactly the same as
the one in /usr/portage/skel.ebuild. Most importantly, do not
modify it in any way and make sure that the $Id$ line is intact.
The first three lines must look like this:
# Copyright 1999-2016 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Id$
Only if you are submitting a patched or version bumped ebuild, should you not
need to modify the $Id$ line. But the line must be present.
It will be expanded on the staging box automatically. So there is no need for you to manually modify it.
See Git to RSYNC.
You should never redefine those variables. Always use MY_P, MY_PN, MY_PV, P0, etc. See other ebuilds that do it in portage for more information. Most ebuilds use bash "Parameter Expansion". Please read the man page for bash to understand how "Parameter Expansion" works.
By the way, if you find a package that re-defines it, don't copy it. Submit a bug about that ebuild.
You should try not to include version numbers in the SRC_URI and S. Always try to use ${PV} or ${P}. It makes maintaining the ebuild much easier. If a version number is not consistent with the tarball/source, then use MY_P. An example dev-python/pyopenal fetches a tarball called PyOpenAL, so we redefine it like:
MY_P=${P/pyopenal/PyOpenAL}
SRC_URI="http://oomadness.tuxfamily.org/downloads/${MY_P}.tar.gz"
S=${WORKDIR}/${MY_P}
There are many things that go wrong with user submitted DEPEND and RDEPEND fields. Here are some important points to follow when you write the dependency part.
>=x11-libs/gtk+-2 and not >=gtk+-2.
>=x11-libs/gtk+-2 rather than
>=x11-libs/gtk+-2*.
This is another very common error. The ebuild submitter submits an ebuild that "just works" without checking if the dependencies are correct. Here are some tips on how to find the correct dependencies.
Another common mistake users make when submitting ebuilds is supplying an
invalid license. For example, GPL is not a valid license. You need to
specify GPL-1 or GPL-2. Same with LGPL. Make sure the
license you use in the LICENSE field is something that exists in
/usr/portage/licenses. As a tip, check the COPYING
in a source tarball for the license. If a package does not specify it
uses GPL-1 or GPL-2, it is very likely it uses GPL-2.
If the license for the package you submit is unique and not in /usr/portage/licenses/, then you must submit the new license in a separate file.
Please do not add other ARCHs into KEYWORDS unless the ebuild has been tested on
that ARCH. Also all new ebuilds should be ~x86 or whatever architecture it is.
Make sure when you bump a version, the stable KEYWORDS are all marked as
~.
Make sure you have the SLOT variable in the ebuild. If you don't plan to use it, don't remove it. Put in:
SLOT="0"
Please check if the HOMEPAGE variable is right and leads users to the right page if they want to find out more about the package. And make sure the DESCRIPTION is not overly long. Good descriptions will describe the main function of the package in a sentence.
It is no fun reformatting lines of ebuilds because the submitter did not follow the guidelines to use TABS rather than spaces. So please use tabs!
I'm often guilty of this. Remember to run repoman over your ebuilds so it can tell you if there is trailing whitespace at the end of lines or on empty lines.
If S=${WORKDIR}/${P}, then you should not add it to your ebuild. This is
implied already, you should only add it if it is something other than
${WORKDIR}/${P}.
If your package has documentation, make sure you install it using dodoc
or in /usr/share/doc/${PF}. Remember to check for errors when
running dodoc/doins.
If the package documentation is large or requires additional
dependencies to build, you should make it optional with the doc
USE flag. If the documentation is small and does not require
additional dependencies (e.g. README files), install it
unconditionally.
Exceptionally, a package may have an unsupported/broken USE flag (this can happen with vanilla or custom-cflags). Then the USE flag must be masked for that ebuild (usually in profiles/base/package.use.mask), at least when the ebuild hits the stable branch.
Please submit ebuilds properly by following the Adding new Ebuild tutorial.
Please please please do not attach ebuilds as tarballs. Attach patches separately as well so we can easily examine them.
Don't cut and paste an ebuild into bugzilla's comment field.
Please let us know what the package is, and fill in the URL with the home page of the application, if any exists.
If you submit a package update, then make sure you explain what changes you made to the ebuild. For example if a package introduces a new features/option and you use a USE flag, list it in your bug. Don't make us hunt for it.
It is wise to submit a diff for a package update rather than the whole ebuild. The best way to generate it would be:
$ diff -u some-package-0.1.0.ebuild some-package-0.2.0.ebuild > ~/some-package-0.2.0.diff
If you are submitting a new version for a package in portage, make sure the existing ebuild works and make sure changes are incorporated in the new ebuild (such as added documentation.) If there are no required changes to the ebuild from the previous version, then don't attach the ebuild. Just say so in the bug report that you copied the ebuild over and verified that the package works and installs properly.