Motivation
My personal motivation for splitting the KDE packages into more granulated packages could be differed into these steps:
- Possibility to only install the wanted applications on my netbook (only 16 GB SSD).
- Some repeating requests in the german fedora forum to split the packages like other distributions.
- Finer package selection on the live images.
Pros and Cons
Pros
- Ability to only install what the user want.
- Small runtime for special targets like netbooks possible.
- cherry-pick the applications in a non-KDE environment.
Cons
- More overhead in metadata (difficult for unstable network connections) (see #Metadata)
- More complexity when installing and updating packages
User experience
- Only install what you need
- Usage of the best KDE apps in other Desktops with a minimum of deps
What I've done so far
I've split the packages on a per-app basis (based on the Specs for F11). So for each binary of a KDE package there is a new subpackage. The subpackages are named this way: <kdepackage>-<binary> (eg. kdegraphics-okular). Where necessary there is also a dependent -libs package (eg. kdegraphics-okular-libs). Commonly used files (such as icons) and files that (may be) used by all subpackages are located in a -common subpackage (eg. kdegraphics-common). Commonly used libraries are located in a common-libs subpackage (kdegraphics-common-libs)
The work done yet is in a very early stage. The focus was on making the initial split to see how it works. The %summary and %descriptions for the new subpackages needs to be added and I've also left out a proper %changelog for now (just increased the %release). Also the upgrade path for packages which don't have a -common-libs subpackage needs to be done.
However, if someone wants to have a look a the specs: http://www.deadbabylon.de/fedora/kde-modular
Abstract
- <kdepackage>-<binary> contains only one application (eg. kdegraphics-okular)
- <kdepackage>-<binary> provides <binary> (eg. kdegraphics-okular provides okular)
- <kdepackage>-<binary>-libs contains dependant libraries for multilib (eg. kdegraphics-okular-libs)
- <kdepackage>-common contains files used by all subpackages (such as icons)
- <kdepackage>-common-libs contains libraries used by all subpackages (when needed)
- <kdepackage> is just a metapackage which requires all subpackages.
Variations
Splitting could also be done in different ways. Some of them would be:
- Do not split on a per-app-basis but on a "popular" basis (eg. the -extras subpackages with no so popular applications like we've done in late KDE3 days.)
- Leave a monolithic -libs subpackage and do not split out the application libraries (eg. no kdegraphics-okular-libs)
Metadata
The metadata would increase when adding more subpackages. This could be difficult for unstable network connections because they had to download more metadata (for each update we do). The following sizes are based on a split of kdegames, kdegraphics, kdemultimedia, kdenetwork, kdepim, kdeutils.
- modularized KDE (484K):
168K filelists.sqlite.bz2 140K filelists.xml.gz 28K other.sqlite.bz2 12K other.xml.gz 96K primary.sqlite.bz2 32K primary.xml.gz 4,0K repomd.xml
- non-modularized KDE (368K):
152K filelists.sqlite.bz2 132K filelists.xml.gz 12K other.sqlite.bz2 4,0K other.xml.gz 44K primary.sqlite.bz2 16K primary.xml.gz 4,0K repomd.xml