Gentoo Development

• If you write a simple ebuild, you still have to place it in the main Portage tree or in an overlay to install it via Portage.

• Emerge app-portage/gentoolkit-dev which contains several utilities needed when developing on Gentoo.

General Ebuild development guide

• A list of important variables available when writing ebuilds:
  • ${S}: Path to the temporary build directory.
  • ${P}: Package name and version.
  • ${PV}: Package version.

• ebuild myebuild-1.0.ebuild digest will create the manifest for you. It must be able to access the distribution file. If the SRC_URI does not work yet, put the distfile in /usr/portage/distfiles directly. You must be root when running ebuild digest.

• Patches must be kept in the files/ directory of the ebuild location if they are small. They should not be compressed.

• Create a patch in the following way:

diff -u original-file.c modified-file.c > packagename-1.2.5-file.patch

Note that it is better to apply patches from the "${S}" directory. That means you have to create the patch in the top-level directory. One way to proceed too is to duplicate the whole source tree and create the patch with the -r (recursive) flag to diff.

• Apply it like this (in an ebuild):

epatch "${FILESDIR}/${P}-file.patch"

• dodoc always acts even if doc USE flag is not set, thus write something like:

use doc && dodoc doc/manual.pdf

• Always use the program echangelog to document your changes. When you're using an overlay, use echangelog-tng (from the package overlay-utils). UPDATE: It seems echangelog-tng no longer exists and its functionality has been merged into echangelog. Set the environment variable ECHANGELOG_USER:

export ECHANGELOG_USER="Jean-Noël Rivasseau <elvanor@gmail.com>"

• Naming Rules: Use syntax like package-1.1_rc2. package-1.1-rc2 is an error. If you create a tarball from a Subversion checkout, name it package-1.1_pre1536 or package-1.1_pre20070628 (revision number or date).

• To clean the temporary work dir, or if anything goes strange, use ebuild clean command.

• Use repoman (which is included as part of Portage) as a QA tool. It will report basic errors in ebuilds. Adjust manually PORTDIR and PORTDIR_OVERLAY environment variables if need be.

• To get the latest version of an installed package, you can use best_version. It will work somehow with SLOTs - you can specify stuff like

best_version =dev-java/package-2.5.6*

Java Ebuild writing guide

• Official Guide

• ANT_TASKS can be set (and should be set) manually on the ebuild, but only in src_compile() or src_test(). Note that ANT_TASKS basically controls the Ant class path, which is different than the one for javac. So -Dgentoo.classpath, for example, does not affect Ant classpath. Nor does it affect the classpath for the <java> task (although this seems to be in development). Currently it only interacts with the classpath for the <javac> task.

• The jar names should not contain version number, if you need to rename them, there is an eclass for that: java-pkg_newjar.

• If a package provides differents APIs, the package should be always SLOTed based on the version of the API.

• If you use eclasses such as java-pkg_getjars twice, the jars will be recorded twice in package.env.

• If some library needs to be used only during the build, use java-pkg_getjars --buildonly. The dependency won't be recorded into package.env.

• To get the dependencies of one library (during ebuild writing), use --with-dependencies. Note that this is a java-config option.

• Inheriting java-ant-2 adds dev-java/ant-core in DEPEND, so no need to add it explicitly.

• If a package installs an Ant task, it should be registered in src_install() with java-pkg_register-ant-task. There should also be an RDEPEND on >=dev-java/ant-core-1.7.0.

• If the package uses an Ant build system with hardcoded classpath inside the build.xml (example: classpath="lib/helper_library.jar"), the best way currently it to use the eclass java-pkg_jarfrom to create a symlink to the Gentoo installed version.

• The following eclass can be used to rewrite an Ant buildfile with your own classpath. The program actually used is /usr/bin/xml-rewrite-2.py, and you can look at the source code to see exactly what can be done.

java-ant_xml-rewrite -f build.xml --change -e java -a classpath -v "${sitemesh_classpath}" || die

Note that the file that has to be rewritten must be valid XML. If it is an included file, just rewrite the file that includes it. It will just get embedded in the included file.

• Report bugs in Java packages both in the main tree and the java-overlay. Don't report bugs in the experimental overlay though.

• When compiling Java code, there are two important options to Ant/javac: -source and -target. -target is the version of the bytecode that will be produced. -source is the version of the Java source. Note that necessarily, target >= source.

• Beware the value of the property build.compiler in Ant files. It can produce bugs, this value may be safely switched to "modern" most of the time.

• Creating a launcher is very easy - just use the java-pkg_dolauncher eclass.