QUOTE(LaNcom @ Apr 4 2005, 21:43)
To install only parts of KDE, don't use the split ebuilds. They are intended for people not running KDE, but with the desire to use at least some KDE apps (Kate, for example). To reduce the KDE applications, add this to your /etc/make.conf (just an example):[right][snapback]585726550[/snapback][/right]
There are numerous advantages to running the split ebuilds over the monolithic ones, as outlined on the page
linked, even if you wish to install all or most of KDE. Use the meta and then emerge -C && emerge depclean, or use /etc/portage/package.provided to keep unwanted packages out.
QUOTE(LaNcom @ Apr 4 2005, 21:43)
DO_NOT_COMPILE="debian noatun kpackage juk krec kaudiocreator kolourpaint kpovmodeler kppp kget kuickshow artsbuilder kedit kmid kscd kfax kiconedit test examples kruler faxview klaptopdaemon charselectapplet kdelirc kjots lisa cervisia kbabel kbugbuster kcachegrind kmtrace kspy umbrello kstartperf kprofilemethod "
This is the old way of doing things, and certainly not the recommended way now that we have proper split ebuilds. Build-time flags are
no substitute for proper package management and dependency handling.
Here is what the Gentoo page says about DO_NOT_COMPILE:
QUOTE
DO_NOT_COMPILE is an environment variable internal to the KDE build system. It allows selectively disabling subdirectories from compilation. Some people used to use it to compile subsets of the monolithic KDE ebuilds. For instance, running
DO_NOT_COMPILE=konqueror emerge kdebase would install a kdebase without the konqueror application.
However, DO_NOT_COMPILE was never intended to be used to interfere with the operation of a package manager's automated builds. It does not work, it can break your system, and it was never supported. We request everyone to refrain from using it.
Here is a partial list of the problems with DO_NOT_COMPILE:
- It completely breaks portage's dependency tracking. Portage does not know about DO_NOT_COMPILE, and thinks the entire monolithic package has been installed and can satisfy other packages' deps. This can cause other packages not to emerge or not to run.
- It forces the user to know the names and meanings of all the different existing subdirs of the KDE modules. Very few users do know this, unless they're KDE developers, so they can't use DO_NOT_COMPILE properly.
- KDE module subdirs can have interdependencies between them, require a particular build order, require another dir to be present even if it does not have to be installed, and so forth. We put a lot of work into the split ebuilds to make them work properly in this regard. DO_NOT_COMPILE is not nearly a fine enough tool to achieve the same results, even given sufficient knowledge on the user's part. The only thing you can do with it is disable a few applications from compiling. It is practically impossible to use it to install only a few selected applications from modules like kdebase or kdepim.
- If I installed kmail yesterday and want to add korn today, using DO_NOT_COMPILE, it entails recompiling kmail as well. This means DO_NOT_COMPILE is always much slower than split ebuilds.
- DO_NOT_COMPILE can't be used to make precompiled packages (such as the GRP) containing individual KDE apps.