[Kde-scm-interest] [Kde-su cm-interest] Package splitting
zander at kde.org
Tue Jan 26 09:56:07 CET 2010
On Tuesday 26. January 2010 01.39.36 Troy Unrau wrote:
> it'd be nice to be able to split out the kde applications
> into separate packages.
Thats not really an scm or a management thing; its a technical thing.
If I look at koffice I see that I just can't split it up without moving a LOT of
cmake code around and duplicating it en-mass.
The dependencies between application and libraries (kdegames, kdeedu and koffice
are good examples there) will mean that you move the dependency checking into
the scm out of the cmake realm. And even if you don't do that and just assume
people will git clone correctly its going to be hell to maintain the cmake
dependency checking stuff.
This topic has been brought up before and at least the edu and the koffice and
IIRC the games people said they don't want to split up. I think that if the
other communities learned about the disadvantages the effect is the same.
>1) We have a mess right now with each distro splitting KDE in a
>more-or-less unique way, except slackware. This makes it hard to
>recommend packages to users when doing tech support.
As far as I know there is no distro that fails to provide a package like
'kdepim' or 'kdegraphics'. So this point I think is just not true. Sounds like
an easier solution is to educate tech support :)
>2) From a marketing perspective, we'd like to start marketing the
>various KDE applications independently, which requires that they are
>easier to obtain as stand-alone apps. In other words, we'd like to be
>able to offer a download of Okular by itself, for instance, since
>Okular is good enough to sell itself.
I fail to see how this requires different tarballs. They still get released all
together with KDE SC. How does marketing affect the tarball used? Or git repo
As long as it technically speaking depends on kde libs and in-module libs you
would just lie to passers by as downloading the git repo of one kdegame still
means you need to get the module-libs.
As I mentioned, this has come up before, we talked about it extensively and
while we have some people that like it, nobody wanted to put the work in and I
think the advantages are just not clear (to me at least).
More information about the Kde-scm-interest