KDE Sub-Packaging Approach on Fedora

First of all, I would like to bring some attention to this post, mostly for Fedora developers, Fedora Extras packagers and people that are in the KDE SIG on Extras. If you are one of these, please read this post 🙂

If you already don’t know, with the Fedora installer (anaconda) being integrated into yum and Fedora Extras, and Red Hat getting all the attention to GNOME, there is a proposal to get KDE into Extras, putting a community effort on it. This is detailed into the Unleash KDE Wiki Page. This proposal explained here is based on these ideas.

The Current Approach

As most of us know, KDE is packaged on a few main “official” packages like: kdebase, kdelibs, kdenetwork, kdeutils, kdegames, and so on. Each one of these packages contains many applications considered “base” on the upstream. With this approach, things get easier when packaging and installing KDE on systems.

For example, on Fedora, installing the kdegames package brings these games for the system: atlantik, kasteroids, katomic, kbackgammon, kblackbox, kbounce, kenolaba, kfouleggs, kgoldrunner, kjumpingcube, klickety, klines, kmahjongg, kmines, knetwalk, kolf, konquest, kpat, kpoker, kreversi, ksame, kshisen, ksirtet, ksmiletris, ksnake, ksokoban, kspaceduel, ktron, ktuberling, kwin4, lskat. Now if I want only kbounce, or konquest? What do I do? I must install all other games.

I talked with many people (20+) and all of them said the same thing: this is really annoying. “There’s got to be a way to install only kopete or kmail, instead of the whole collection of programs”. Everyone says that this will be a lot better to the user. But we know that for us packagers and maintainers, this brings more difficulty into our hands.

The Solution: A Sub-Packaging Approach

This is already used in some distributions, and users appear to like it. The solution would be to use a sub-packaging approach, and that means we have many sub-packages independent one from the others (with a common package containing common files used by all) and a main meta-package that requires and installs all these sub-packages.

For example: a single kdenetwork.src.rpm would create the packages: kdenetwork (meta), kdenetwork-common, kdenetwork-kdict, kdenetwork-kget, kdenetwork-kopete, kdenetwork-krdc, kdenetwork-ksirc, kdenetwork-kwifimanager, and so on. A single kdegames.src.rpm would create the packages: kdegames (meta), kdegames-common, kdegames-kpat, kdegames-kbounce, kdegames-konquest, kdegames-kasteroids, kdegames-kmines, kdegames-kolf, and so on.

ChitleshGoorah suggested: instead of kdenetwork-kopete, the package should be named only kopete. This is because when someone tells the user to install kopete, the first thing that the user will try to do is: yum install kopete, and not yum install kdenetwork-kopete. This could be resolved adding a Provides: kopete into the specfile for the subpackage: this way user can reach the package both ways (kdenetwork-kopete will exist for organization purposes).

Now if someone (or the installer for example) wants to install the whole package, just yum install kdenetwork. The package requires all sub-packages but the sub-packages does not require this meta main package. So if I want to uninstall something, removing only the packages kdenetwork and kdenetwork-kopete will work, leaving all other packages alone.

Some other people from other distributions have talked to me, telling that separating applications into sub-packages gives a boost at customization. I know a distribution that has packages divided into many ones (compared to Fedora) and people always says that this is perfect for creating customizations and derived distributions. Most of the customized distributions I know are based on this distribution. We have to agree on this: this is a great way to get marketshare. More work, sure, but quality and advantages for everyone 😉

Downside: Maintainership

While having these advantages above, we gain a more complicated specfile, meaning more difficulty to the maintainers. The specfile grows bigger with sub-packages, and the maintainers should do a initial work on describing all the applications, separating all specific files for each sub-package, manage dependencies well, and so on. Now this is my question: Is it worthy to get this new approach and get these extra difficulties? I want to know what Fedora People think 🙂 Some of them already likes it, some don’t because of the concern about taking responsability.

As I’m determined to do this (and I don’t want to try to step on anyone), I began doing the initial work on the packages. If we agree on this, we could form a KDE maintainers group based on the KDE SIG, pretty much like we have today with Perl, Security, and so on. This will easier the maintainership for those packages. Come on everybody, please comment on this and say what you think about it 😉

An Example is already made: kdegames

Yeah, I know, talk is cheap, show me the code. Thinking on this, I created an example of this approach, working and compiling within Fedora Core 5 or rawhide. It’s based on Rex Dieter’s Package Review on kdegames. The specs and SRPMs are linked on bugzilla too.

The current specfile for kdegames:
http://www.devin.com.br/eitch/fextras/SPECS/kdegames.spec

Please read the comments in Bugzilla too for more explanations. Thanks and sorry for the long posting 😉