Stabilizing 3.4 and later - a case for gnome split ebuilds?

dirk_salewski

Hello NG,

since more than a year now I'm quite happily using gnome 3.2. But as anyone using gnome 3.x knows, this is only possible with a very bloated package.keywords. I remembered the KDE team having problems with monolithic KDE builds many years ago and found Das KDE Split Ebuilds HOWTO (german unfortunately). This document describes probably exactly the problems with monolithic gnome at the moment, and it describes how the KDE people dealt with it by introducing split ebuilds.

If we had gnome split ebuilds, it would be possible to stabilize "gnome-base/gnome-main-meta" (which would probably resemble todays gnome-light) without waiting for the last silly game to stabilize upstream.

In short the list of identified benefits by the KDE people:

Minor releases don't mean any change for the majority of packages. Updating only needed ebuilds saves compile time (probably more relevant back in 2005, when people used slow single core pocket calculators as their computers)
Patches usually can be incorporated faster, since a patch normaly applies to only a few programs. This IS still relevant - patched up-to-date means sort of secure. And fixing only a few ebuilds means lower impact on sparse dev resources. This is probably the most important point - are we waiting for gnome 3.4 to stabilize due to every gnome dev regression testing everything again when aisleriot upstream releases a new version?
Users of other DE could use single gnome applications without compiling a whole DE first.
Monolithic ebuilds force you to install programs you probably don't want. That is the opposite of the Gentoo Way.
Flexibility in terms of USE is bigger with split ebuilds

Now - I can't say whether all of this is relevant when it comes to gnome. But I definitively can say that I'd like to have a stable gnome 3.x by now, even if it was without the latest silly game.

What do You think?

Greetings

Dirk
_________________
Egal was Du kochst: Karl Marx.