[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

KDE Sub-Packaging Approach on Fedora

Hi list,

I have just submitted a blog post on this:

And I'm bringing this discussion into the list too. I'll paste the post here 

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 

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 

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:

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


- Using -n in the subpackages %package could give us the "simple package name" 
instead of using "Provides:". Is it better? It will not polute the specfile? 
Opinion: Some think it's better. If it really is, task for Eitch: make 
changes into the kdegames example.

- Bring this into FESCo attention?


"Talk is cheap. Show me the code." - Linus Torvalds

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]