KDE Sub-Packaging Approach on Fedora
Hugo Cisneiros
hugo at devin.com.br
Sat Jun 17 21:20:43 UTC 2006
Hi list,
I have just submitted a blog post on this:
http://www.devin.com.br/eitch/blog/2006/06/17/kde-sub-packaging-approach-on-fedora/
And I'm bringing this discussion into the list too. I'll paste the post here
too:
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 ;-)
Updates:
=======
- 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?
--
[]'s
Eitch
http://www.devin.com.br/eitch/
"Talk is cheap. Show me the code." - Linus Torvalds
More information about the fedora-extras-list
mailing list