From Gentoo Linux Wiki

[edit] Overview

As of late, the portage team has split the 15 standard KDE ebuilds into over 300 different ones for version 3.4. This was done for a number of reasons (from http://www.gentoo.org/doc/en/kde-split-ebuilds.xml):

• Most KDE packages aren't changed at all between minor KDE releases. For example, the update from 3.3.1 to 3.3.2 changed fewer than 100 packages out of 320. Split packages allow us to create new ebuilds only for the packages that are actually changed, saving (in this example) more than two-thirds of the compilation time on an upgrade.
• Patches usually affect a specific package. With split ebuilds, they can be tested, approved and committed faster, and the developers have less to do; and, as above, the user will spend less time upgrading. This is especially important for security updates.
• Users of other desktops and leaner WMs can emerge a few KDE apps they like without the (quite big) overhead of the rest of, say, kdebase or kdepim.
• Users can fine-tune the packages they have installed. Reasons you might want this include:
  • You care about compilation time. emerge kdebase kdepim kdenetwork takes far too long when what you really need is konqueror, kmail and kopete. Besides, CPU time is energy... somewhere.
  • You care about disk usage. Every unused package is that many megabytes blocking the pores between your disk's sectors. A disk with more free space breathes freely; it's a fast, happy disk.
  • You care about system security. All installed software is a potential source of vulnerabilities, and there's no excuse for unused software left lying around.
  • You faithfully adhere to the Gentoo Way, and can't stand packages being bundled together and forced on the user. (Neither could we.)
• Finally, the split ebuilds also allow more compile-time flexibility with USE flags.

Gentoo has provided a nice document at http://www.gentoo.org/doc/en/kde-split-ebuilds.xml describing the rationale behind the split ebuilds, but there is nothing that really describes the basic mechanism for starting with the new KDE split-ebuilds, or upgrading from KDE3.3. This document will attempt to do that.

[edit] Upgrading to KDE 3.4/3.5

NOTE: Below when the instructions include the <arch> notation, please replace that with your machines architecture. For example, if you are building on an Intel x86 architecture, you'd replace <arch> with x86.

[edit] Decide whether you want to still use "monolithic" KDE, or the new "split" kde

As with everything in gentoo, you have a choice. With the new KDE split ebuilds, your choices are growing (and to some this is quite daunting). Basically what you need to do now, is to determine if you want to continue to use "monolithic" KDE, or if you want to take advantage of the split ebuilds. The first method is by far the easiest, and the second is by far the most flexible.

[edit] Using "monolithic" kde3.4/3.5

NOTE: This will not work forever, but it does provide an easy migration path to KDE 3.4/3.5.

So you've decided you want the pieces of KDE as the KDE projects defines them. No problem!! for now, the portage team has made the existing 15 monolithic KDE packages interoperable between 3.3 and 3.4. All you need to do is this:

1. If you want to get the whole KDE then all you need to type is :

2. If you only want parts of the monolithic kde, then 'emerge kdebase' and then pick and choose from the following other kde packages:

• kdeaccessibility
• kdeadmin
• kdeartwork
• kdeedu
• kdegames
• kdegraphics
• kde-i18n
• kdemultimedia
• kdenetwork
• kdepim
• kdesdk
• kdetoys
• kdeutils

[edit] Using split KDE 3.4/3.5

If you want to get the whole KDE then all you need to type is :

Emerging only the what you need of KDE 3.4 is a bit more time consuming for a couple of reasons. The compiles take longer (at least right now, it seems the Portage team is looking into this), and because you are going to need to search through portage to find the packages you want. Below I'll describe how to get a working base KDE 3.4 system. From there you can pick and choose which other applications to install.

[edit] Optional: Removing all of the old KDE components

This step will clean your machine of legacy KDE 3.3 components. Before you do this, however, you may want to go through the KDE menu in your existing setup and make a list of the applications you are going to want to use with KDE 3.4. Needless to say, if you are setting up a new machine, you can safely skip this section. As well, the new KDE *should* install in a new slot, so this step is not entirely necessary.

1. First you need to install the gentoolkit. This is needed because we are going to use the equery utility to find all of the kde packages currently installed on our system.

2. Next we will use a little bash magic and the equery utility to find all of the installed kde packages (this will only get rid of the packages that are in one of the kde-* categories, there may be a few things left behind). This will probably take a bit of time:

3. Now you probably want to issue the following command to see if there was anything left behind and unmerge it yourself (this will list all of the packages installed on your machine):

After you are comfortable that you have gotten all of the old kde applications, then you can follow on with the next step.

for those who this removing method doesnt work you might want to try this:

review the packages in the kdepackages file just created. Then:

(you might want to remove the --ask if you are positive that you want to remove all the packages listed in kdepackages)

(optionally, if you wish to remove an older version of KDE after you have installed the newest version, you can do:

to remove 3.3 packages for example. Same code can be used to remove other versions, just replace 3.3 by another version number.)

Or the most simple and working:

emerge -Ca /var/db/pkg/kde-base/*-3.4.*

[edit] Installing a minimal KDE 3.4/3.5

The easiest way to get kde up and running is by starting with the kde-base/kdebase-startkde package. This package has all of the dependencies necessary to get a minimal KDE environment up and running. To do this the following steps are required:

1. Unmask the following packages:
   • kde-base/kdebase-startkde
   • kde-base/kcminit
   • kde-base/kdelibs
   • kde-base/ksplashml
   • kde-base/ksmserver
   • kde-base/kwin
   • kde-base/kpersonalizer
   • kde-base/kdesktop
   • kde-base/kdialog
   • kde-base/kdm
   • kde-base/kcontrol
   • kde-base/khelpcenter (added because of dependencies 2005.1 26/01/2005)
   • kde-base/kdesu (added because of dependencies 2005.1 26/01/2005)
   • kde-base/khotkeys (added because of dependencies 2005.1 26/01/2005)
   • kde-base/kicker (added because of dependencies 2005.1 26/01/2005)
   • kde-base/kdebase-data
   • kde-base/libkonq
   • kde-base/kdepasswd
   • kde-base/kcheckpass
   • kde-base/kreadconfig
   • kde-base/arts
   • media-libs/openexr (only needed if the openexr USE flag is enabled)
2. emerge kdebase-startkde

This will take a while to complete. Once finished you will have a minimal, but (barely) usable, KDE environment available. You can test your new KDE environment by invoking startkde at the command prompt (I assume you already have Xorg working). If everything went well you should see a default KDE background (I believe that this is blue). Right clicking should give you the standard desktop menu with options like "Run Command...". There will be no kicker panel.

[edit] Extending the minimal environment to be a more user-friendly

If you ran the startkde script after emerging it, you probably noticed that the KDE environment was quite basic. Specifically, there was no kicker and only the right-click menu was available to you. This can be remedied by unmasking and emerging the the "kicker" package. Additional packages that are highly recommended to be installed in addition to kicker are:

• kicker-applets – installs the kicker applets (like the clock)
• kpager – an application to help with paging between virtual desktops
• kmix – allows you to adjust the multimedia volume from within KDE.
• kscreensaver – provides the screensavers for KDE.
• kxkb – allows to switch between more keyboard layouts, adds Keybord Layout options into Regional & Accessibility section of the Control Center

These are a bit larger, but also help to make your desktop much more functional:

• kdebase-kioslaves – KDE's file management library. For example, you won't be able to put anything in your Desktop trashcan without it.
• konqueror – KDE's file system browser, as well as web browser. With this, you can actually see what's in your trashcan. :)
• konsole – who can live without X terminal in KDE?

taskara has a mini-HOWTO over at the Gentoo Forums that provides an alternate listing of packages that are recommended to be installed.

[edit] Adding additional KDE applications

From this point on, you can emerge any additional KDE applications you want. Most are found under either the kde-base or kde-misc categories in portage. You can use a service like http://packages.gentoo.org or http://gentoo-portage.com to browse them, or you can look in the /usr/portage/kde-* directories to see the available packages and use emerge -s, esearch, eix or equery to find out more information about them.

[edit] Speeding up the compile

As you may have noticed, the split ebuilds are slower at emerging. This is caused by a few initial design decisions that will likely be corrected in the future. From http://www.gentoo.org/doc/en/kde-split-ebuilds.xml:

It's been said before that split ebuilds would take much more
time to emerge than the monolithic ones, due to the overhead of
unpacking and running configure for every package. A complete
emerge kde-meta could take 20-30% longer than a classic emerge
kde, unacceptable in an already long compile.

Moreover, at present the split ebuilds always run make -f admin/Makefile.cvs
(this means running autoconf, automake, etc. and several related
kde-specific scripts). This adds an additional slowdown of
approximately the same order as a configure run.

On the face of it, this analysis looks bleak. However, several
factors which offset this slowdown will be detailed in the next
sections.

It is worth reiterating here that with the split ebuilds a KDE
upgrade's compilation time can be cut by half - and in some cases
by a factor of ten or more - by only upgrading the packages that
actually changed. The benefit from a single such update often
overshadows the overhead incurred during the original installation.

Finally, installing all of KDE makes sense if you want to explore
the available packages or are setting up a multi-user environment;
however, most people use only some of the 300+ KDE apps available.
Anyone who really cares about compilation time, such as owners of
older boxen, can gain more time by selectively installing packages
than they might lose by the overhead incurred."

Fortunately, until these things are "fixed", you still have some options:

• enable the "kdeenablefinal" USE flag - Do not enable this unless you have a lot of RAM. Run euse -i kdeenablefinal if you have gentoolkit installed for more info.
• emerge ccache and enable "ccache" in the the FEATURES of /etc/make.conf (this FEATURE is enabled by default on most recent gentoo profiles).
• Use distcc if you have more than one PC available. See http://www.gentoo.org/doc/en/distcc.xml, HOWTO Distcc server on Windows and TIP AMD64-x86-distcc for more info.

In addition, users with a slow internet connection can enable the "kdexdeltas" USE flag (euse -i kdexdeltas for more info) so that binary diffs are downloaded instead of the whole KDE packages.

[edit] Unmasking all KDE 3.4/3.5 packages

It can be a bit tedious running emerge and unmasking one package at a time in order to install KDE 3.4. If you have no reason to object, you can quite easily unmask most KDE 3.4 versions with a bit of bash scripting. Since all of the KDE project provided packages reside in the /usr/portage/kde-base and /usr/portage/kde-misc directories, all we have to do is look at the portage tree on our local machine (you may want to emerge --sync if you haven't for a long while before continuing) and then add those packages to /etc/portage/package.keywords:

This will add all packages in the aforementioned categories to the packages.keywords file.

The above "one liner" is meant to be easier to copy/paste and will only add kde*3.5* packages to the packages.keywords. You simply change the 3.5 above with the version you want (ie: you could type 3.5.0 too...). --Kyron 15:23, 21 February 2006 (GMT)

Alternatively, you can use taskara's script from his thread on the topic:

[edit] Upgrading only installed packages and their dependencies

If you only want to upgrade the split packages you already had under say, KDE 3.4, the following line will come in handy:

This way, you only upgrade relevant KDE packages you already had installed without adding dependencies explicitly in the world file. This is sometimes much more interesting than performing an emerge world with all its implications

[edit] Re-emerge all installed kde packages if something is broken

If you ever need to recompile everything of kde (e.g. after an Qt update), then you can use the following command.