Gentoo Development
Jump to navigation
Jump to search
System configuration
- Your ~/.cvsrc file should contain the following:
cvs -q -z0 diff -u -b -B checkout -P update -d -P
- You should add FEATURES="test" to your make.conf file. Note that the test USE flag on the ebuilds is only used to trigger additional dependencies that may be required for testing. This test USE flag is automatically on if you have FEATURES="test", thus you cannot turn off tests per package via /etc/portage/package.use. It is even hard to turn off tests per package, the only way is manually emerging with FEATURES="-test" the problematic package.
Overlays and layman
- Overlays are additional ebuilds repertories in addition to the main, stable Gentoo tree. As such they are useful for development activities or hosting of unstable ebuilds.
- layman is a tool for overlay management. It uses a list of overlays. This list is stored somewhere (generally on a remote server). The main configuration file for layman is /etc/layman/layman.cfg.
- When adding URI for overlay lists in that file, be sure to add a space or tab before every new line! This is mandatory, else layman won't parse the file correctly. I personally consider this a bug...
- Unofficial overlays can be listed with the -k (nocheck) switch:
layman -L -k
Useful tools
- pkg-config is a tool that is used to keep trace of the configuration and install options of packages. For example, it can gives you the C flags options, or the value of a specific variable (sdkdir for xulrunner). It creates *.pc files that are stored in /usr/lib/pkgconfig (on Gentoo). You query these files with the command-line pkg-config tool.
General Ebuild development guide
- 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.
- The PORTDIR environment variable controls the location of your Portage tree.
- A list of important variables available when writing ebuilds:
- ${S}: Path to the temporary build directory.
- ${D}: Path to the temporary install 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. Note however that patches are a pain to maintain when doing version bumps. Especially if a patch is applied to a set of files. Consider using sed if you can.
- 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>"
When creating or copying a new ebuild, the ChangeLog file should be deleted. Once echangelog is ran, it will be created and then can be added to CVS / SVN.
- 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*
best_version is an helper function.
- All packages should specify a slot. Those that don't need slotting specify SLOT="0".
- For metadata.xml, use the skeleton in /etc/portage/skel.metadata.
Versions
- The "*" symbol cannot be used with >= style syntax in DEPEND or RDEPEND; only with "=".
Install Step (src_install)
- doins will NOT respect file permissions. You need to use doexe or dobin if you need to install executable files.
- doins will also act strangely with respect to empty directories. It may not create them. In this case you should use dodir or cp -r to copy a hierarchy of directories to the image install location.
- Changing permissions of files work normally using chmod.
Profiles
- The new way of laying out profiles is arch/ia64. There is also default/linux/ia64. The default-linux directory seems to be deprecated.
Java Gentoo Development
- Some additional knowledge is required when writing Java-based ebuilds.
Specific Ebuilds
Upstream Actions
- Contacted Groovy ML to try to get an option to disable Maven entirely in the build.