1 General information
Every KDE release introduces new applications and often new external dependencies. The KDE project provides categorized source packages. For example, kdenetwork includes network related applications. We call those categories "modules".
Within those modules are separate directories for each application which often don't depend on each other. For example, if you install kdeutils to use the Ark-libre archive manager, you'll get a printer-applet which cannot be disabled.
This does not only increase disk usage a lot (and internet bandwidth) it will also add dependencies and features you might not want or need. E.g. you install a soundmixer kmix and you'll get some audioplayer which are associated with a lot of file types, too.
Using makepkg from pacman 3.3 we are now able to create several packages with one PKGBUILD. Every module will be split into its single applications.
1.3 Pro splitting
- decrease dependencies
- between KDE packages and external packages which use KDE-libs (like KOffice, Amarok, Digikam)
- decrease disk space and download bandwidth
- choose which apps and features are installed and enabled
- install KDE or KDE related packages on non-KDE desktops without the need of installing nearly the whole KDE itself
- search and find applications using pacman
1.4 Contra splitting
- more initial work for packages
- used a script generator to compensate this a bit
- major updates are more complicated
- a script will help to detect new and removed sub modules
- Do KDE devs want their packages to be split?
- There are some docs about how and which should be splitted within the KDE source packages.
- Aren't splitted packages against Parabola K.I.S.S. principle?
- Even the larger PKGBUILDs (like kdegames) are very simple and not complicated at all. There are no patches or strange workarounds needed to make splitting possible.
2.1 Package Policy
- split by sub modules suggested by upstream (cmake subdirs in each module)
- include its documentation in each sub module
- don't split across sub modules (e.g. -doc or -devel packages which include files of several sub modules)
- split by application or feature
- don't split libs or data sub modules which are not used by more than one other module.
- every sub module has the module prefix: e.g. kdeutils-ark-libre
- every sub module should be in the module group. E.g. kdeutils-ark-libre is member of the kdeutils group
- sub modules which don't include any application (e.g. libs, data) shouldn't be members of any group
- don't split essential modules on which many other packages depend (kdelibs, kdepimlibs)
- sub module definitions and package functions should be in lexicographical order
- use upstream names for sub modules
- don't build sub modules which are disabled upstream (see cmakelist)
2.2 Update path
Introduce a kde-meta package set which handles all depends, conflicts and makes an update to splitted packags smooth. It can also be used to keep track of all new packages a major release might introduce.
- don't clean the build dir. So you can use -R to repackage. This way one can change everything outside the build function without the need of compiling again. You can even add or remove sub packages.
- KDE source packages (even in the sub packages dirs) include some docs about splitting/deps and package description. (sadly not standardized; so it can not be scripted)
- Don't forget about deps namcap does not detect (python, icons, other data)