Project:GNOME/Gnome Team Ebuild Policies

This page is a draft.

This page is intended to link or to write down Gnome team policies about its own packages or how packages using Gnome team packages as dependencies should handle some particular aspects.

EAPI
Gnome team tries to stay up-to-date with regard to the best available EAPI. Currently this is EAPI 5.

Gnome team goal is to have all ebuilds use that EAPI and make best use of its features such as:
 * subslots
 * default configure flags
 * default installed documentation (generally no need to define DOCS)

Eclass usage
Gnome team provides a wide range a functions through its eclasses. Some people see it as bloat, but this is only the bare minimum to ensure packages using Gnome libraries work fine once installed. The amount of code is only the result of keeping backward compatibility with old systems such as scrollkeeper but there is really nothing to fear from the eclass, much more to get wrong by not using it (not regenerating mime and desktop database being the most common example).

Users of the eclass are, obviously, required to pay attention to eclass changes. Most of the time, if not always, they are announced/reviewed on gentoo-dev mailing list and there is little effort to do to keep up to date.

G2CONF and src_configure
This variable has a long history. Recently, on gentoo-dev mailing list, someone brought up the issue that most Gnome ebuilds did configure work in pkg_setup instead of src_configure and this caused extra run-time for no reason for binary packages.

In response to that valid concern, the Gnome team updated its policy to always define a src_configure when there is something to configure and pass configure switch to gnome2_src_configure function. Since G2CONF had no other use than defining configure information in pkg_setup, most of its use if now gone and it should be removed from ebuilds.

For example, fictitious ebuild:

will translate to:

GCONF_DEBUG
Policy being defined at bug #270919.

GNOME2_LA_PUNT
Needs writing, especially with regard to behavior with EAPI=5.

gtk-doc
gtk-doc is the framework for documenting libraries for developer audience. It provides tools to extract, compile and install documentation from the source code of the library directly. In Gentoo, this used to be handled by USE=doc for all packages using gnome2.eclass however the behavior was not fit to what users expected.

After much discussion gnome team came to the following conclusions:
 * gtk-doc must always be installed. gtk-doc is part of the package as distributed by upstream (pre-built), hence it costs no extra CPU time, no extra dependencies and has relatively low disk space requirements. Corollary, there is no need to rebuild documentation, so just pass --disable-gtk-doc to configure.
 * gtk-doc must be installed in /usr/share/gtk-doc. gtk-doc is a framework for documentation, just like any other framework, files targeted for it must be usually be installed in a defined place to be any useful (such as in devhelp). Also, until there is a better solution, this allows users to easily avoid any gtk-doc documentation if they have no use for it by using install-mask feature.
 * All packages using gtk-doc must DEPEND on gtk-doc-am. This package provides macros for autoreconf and tools to relink installed documentation to local resources instead of http://library.gnome.org.

introspection
The introspection USE flag is used to control whether or not a package should install its gobject-introspection description files. This is currently mainly used throughout Gnome for using regular C libraries transparently from languages such as python and javascript.

Current policy is:
 * make support optional only when it is possible
 * make use flag default enabled when support is optional. Since it is used throughout the Gnome desktop, it is simpler to default it to be enabled since most user will want it and will not want to change this USE flag on a per-package basis when portage will check the dependencies. Exceptions are system packages such as udev until libgudev is eventually split.
 * in all cases make sure to add [introspection] or [introspection?] (depending on the case) to required dependencies according to build system information and .gir files.

gtk3
Since the release of gtk+-3, Gentoo has three gtk+ slots in tree. Long ago, packages tried to handle support for both gtk+-1 and gtk+-2 by using USE=gtk and USE=gtk2. However this proved to be confusing. Some packages would have both when actually only one was useful. Some other packages only had USE=gtk for gtk+-2 support. These two simple examples shows that this was the wrong approach. It created much more support than necessary and users were not happy.

At the time gtk+-3 was added to the tree, it was discussed on the mailing list and approved by other Gentoo developers that having only USE=gtk to mean "Enable gtk+ related support" was the best way to go. This means that having USE=gtk3 to enable gtk+-3 instead of gtk+-2 support is forbidden.

This still leaves a few questions for maintainers to resolve hence the following policy:
 * package is an application with support for multiple gtk+, maintainer is free to select whatever slot he desires to support. It is strongly advised to use gtk+-3 if functionality is equivalent. This is to reduce workload of bugs being triggered with one slot but not the other.
 * package is a library shipping gtk+ based library only, it must be slotted. Working with upstream on this might be needed for those who do not understand the principles of soname and soversion.
 * package is shipping gtk+ based libraries and gtk+ based utilities. Package must be slotted and binaries should be suffixed with slot.
 * package is shipping gtk+ based libraries and non-gtk+ based libraries or utilities. Package should be split or if maintenance cost is too high, USE=gtk and USE=gtk3 is allowed to enable support for gtk+:2 and gtk+:3 respectively. This should concern a minority of packages like avahi, gtk-vnc, spice-gtk, etc.

Please note that loading a gtk+-3 based library in a gtk+-2 application will fail and crash the application so it is important to properly depend on relevant USE flags and slots.

Remember: gtk USE flag means gtk+ support, whatever slot is needed by the package using it

ssl
This is not a Gnome team policy per see, just a reminder from old discussions on gentoo-dev mailing list.


 * in case a package supports SSL or TLS for whatever it does with it, it must present this behind a USE=ssl flag.
 * in case multiple SSL backend library are allowed, they must each be presented by a corresponding USE flag, except for the maintainer chosen default and be enabled only when USE=ssl and USE=${support-lib} is set.

For example, library foo has optional support SSL through gnutls, openssl and nss. It will have IUSE="ssl gnutls nss". If user want to enable SSL, he/she will just emerge the package with USE="ssl". If he/she wants SSL support through gnutls, he/she will emerge the package with USE="ssl gnutls".

This policy probably needs updating due to EAPI 4 and 5 features.

static-libs
The Gnome team does not try to provide static libraries for all packages. This is not by laziness, this is just because most libraries being based on gtk+ and gtk+ not being static-linking friendly, this is not something we can have the luxury to spend our time on.

We only add support for static libraries on user request.

If for some reason your package provides static libraries, you are free to allow building them behind USE=static-libs, which is the current practice across the tree, as long as you can ensure that it does link correctly of makes working executables.