• stable: eclass-based modular sub projects (kinda like gstreamer)
• testing: monolithic gtk-sharp

As currently implemented, these approaches are not only incompatible, but difficult to support simultaneously in ebuilds that DEPEND on them. To preserve the two-prong status quo sustainably, the dotnet team would probably need to create virtuals to prevent a profusion of DEPENDenceies like:

( || ( <=dev-dotnet/gtk-sharp-2.12.13[foolib] dev-dotnet/foo-sharp))

from appearing all over the place which, although probably legal in EAPI5+, will anyhow bring portage's dep-solver to it's knees, in practice, causing all kinds of spooky disasters whenever any structural change occurs and general slowness any time --complete-graph evaluation occurs.

I think the questions that need answering are:

• How much benefit is derived from the modular ebuilds as compared to the monolithic approach?
• Is there a good reason to maintain both or can we pick one or the other approach and treeclean the other out of existence?

How Gtk+ is packaged in stable and testing branches?

KEYWORDS

The KEYWORDS variable in an ebuild file is also used for masking a package still in testing. There are architecture-specific keywords for each package that let portage know which systems are compatible with the package. Packages which compile on an architecture, but have not been proven to be "stable", are masked with a tilde (~) in front of the architecture name. emerge examines the ACCEPT_KEYWORDS environment variable to allow or disallow the emerging of a package masked by KEYWORDS. To inform emerge that it should build these 'testing' versions of packages, you should update your /etc/portage/package.accept_keywords file to list the packages you want the 'testing' version. See portage(5) for more information.

--complete-graph evaluation

--complete-graph [ y | n ]

This causes emerge to consider the deep dependencies of all packages from the world set. With this option enabled, emerge will bail out if it determines that the given operation will break any dependencies of the packages that have been added to the graph. Like the --deep option, the --complete-graph option will significantly increase the time taken for dependency calculations. Note that, unlike the --deep option, the --complete-graph option does not cause any more packages to be updated than would have otherwise been updated with the option disabled. Using --with-bdeps=y together with --complete-graph makes the graph as complete as possible.

--complete-graph-if-new-use < y | n >

Trigger the --complete-graph behavior if USE or IUSE will change for an installed package. This option is enabled by default.

--complete-graph-if-new-ver < y | n >

Trigger the --complete-graph behavior if an installed package version will change (upgrade or downgrade). This option is enabled by default.

--with-bdeps < y | n >

In dependency calculations, pull in build time dependencies that are not strictly required. This defaults to 'n' for installation actions, meaning they will not be installed, and 'y' for the --depclean action, meaning they will not be removed.

--with-test-deps [ y | n ]

For packages matched by arguments, this option will pull in dependencies that are conditional on the "test" USE flag, even if "test" is not enabled in FEATURES for the matched packages. (see make.conf(5) for more information about FEATURES settings).

what is gx86?

Stetic