Gentoo Logo

Gnome Project Policy

Content:

1.  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.

2.  CFLAGS Support

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.

3.  Libtool Archives and Static Libraries

Application Plugins

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.

Libraries

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.

Warning: 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 endeavours.

The variable G2PUNT_LA="yes" should be used to remove .la files in the src_install stage for packages using gnome2.eclass

Warning: This will remove ALL .la files from the package. Specific removal will have to be done manually.

All libtool related information is taken from blog posts by Diego E. "Flameeyes" Petteno

4.  Bug Priority

Bug priority table

Priority Description
Pri-1 Major bugs in the desktop. This will also include Trackers (so the trackers are easy to find).
Pri-2 Most bugs in the packages we maintain that have been verified as "real" bugs and require fixing. Also includes version bumps.
Pri-3 Bugs identified as "user-specific", those that aren't verified and are most likely to do with a specific users settings/issues.
Pri-4 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.
Pri-5 The Gentoo Gnome wishlist


Print

Page updated October 1, 2009

Summary: This the policy document for the Gnome Project

John N. Laliberte
Author

Daniel Gryniewicz
Author

Nirbheek Chauhan
Author

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.