Gnome Project Policy
Meta Ebuild Policy
The Gnome Herd maintains a meta ebuild named gnome. This meta ebuild is intended to
install all of the packages considered by the upstream GNOME project as being part of the
Gnome Desktop. It is not intended to be customizable, with two exceptions: hardware
customization (cdr, dvdr, hal), and accessibility. This is the recommended method of
installing the Gnome desktop on a Gentoo system.
The primary alternative, if you require specific Gnome programs, is to emerge them
individually. If, for example, you want to use Evolution for email, you should emerge
evolution. This should pull in any necessary dependencies to run evolution.
There are many subsets of Gnome that can be installed and usable. There is no way that
the Gnome Herd can support them all, or any significant fraction of them. We do make one
such subset available: gnome-light. This subset is intended to include the programs
necessary for basic desktop functionality without any additional applications. It
basically includes gnome-session, gnome-panel, gnome-terminal, nautilus, metacity, and
yelp. This is a session manager, a start menu/panel, a terminal program, a desktop, a
file browser, a window manager, and a help browser. This subset is largely unsupported
(as none of the Gnome Herd members actually use it), but we will fix problems with it as
we can. Gnome-light can be used as a jumping-off point for installing intermediate
subsets of Gnome between it and the full gnome meta ebuild, by emerging extra
applications as necessary. No other subsets, including making the gnome ebuild more
customizable with USE flags, will be supported.
Upstream GNOME does not support any advanced CFLAGS beyond -O2, and neither does the
Gnome Herd. Unreproducable bugs with any CFLAGS beyond -O2 and appropriate -march
are liable to be closed as INVALID unless they can be reproduced with valid CFLAGS.
Libtool Archives and Static Libraries
If the application does not use the libltdl wrapper to load plugins,
and just directly uses dlopen(), the libtool archive (.la) files can be removed
safely. Use strace -e open $cmd to see the sequence of files opened till
the .so associated with the plugin is loaded. If the corresponding .la file is
not accessed, it can be punted. If static libraries are installed with the
plugins, they should be removed as well after verifying that they are not used.
Static libraries are useless for programs linking against GTK+ because it uses
dynamic linking. Hence, static libraries should only be kept for programs
linking against dev-libs/glib and/or the GNOME C++ bindings. For the
rest, they should be disabled by passing --disable-static to configure.
For a specific libtool archive file:
- If the library is an internal library, simply remove the .la file and the
corresponding static library.
- If a static library is not installed (only a shared library), the .la is a
candidate for removal.
- If a static library is installed, but it has no dependencies, the .la is a
candidate for removal.
- If a static library is installed, and it has dependencies, and the package
officially uses pkg-config for managing static libraries (for example:
net-libs/xulrunner), the .la is a candidate for removal.
Once a .la file is a candidate for removal, potential breakage must be
evaluated. See "removing" below.
Removing Libtool Archive files
Once it has been verified that the .la file is a candidate for removal, the
breakage that will come about due to it's removal must be evaluated. If it's a
new package, there will be no breakage, and hence the .la file should be removed
before adding to tree. If it's an existing package, the breakage might not be
worth the benefits of removing it. Team approval should be sought before such
The variable G2PUNT_LA="yes" should be used to remove .la files in the
src_install stage for packages using gnome2.eclass
This will remove ALL .la files from the package. Specific removal will have to
be done manually.
All libtool related information is taken from
by Diego E. "Flameeyes" Petteno
Bug priority table
Major bugs in the desktop. This will also include Trackers (so the trackers are easy
Most bugs in the packages we maintain that have been verified as "real"
bugs and require fixing. Also includes version bumps.
Bugs identified as "user-specific", those that aren't verified and are most
likely to do with a specific users settings/issues.
Requests for new ebuilds that we'd like to maintain, time permitting.
Requests for new ebuilds that we don't want to maintain should be
re-assigned to maintainer-wanted.
||The Gentoo Gnome wishlist
The contents of this document, unless otherwise expressly stated, are licensed under the CC-BY-SA-2.5 license. The Gentoo Name and Logo Usage Guidelines apply.