[Kde-scm-interest] Package splitting

[Oswald Buddenhagen]

> On Tuesday 26. January 2010 01.39.36 Troy Unrau wrote:
> > Thiago told me that ossi has already brought this
> > up somewhere, but I haven't grepped through the archives yet.
> > 
over and over, in fact. funnily, people are preferring to polish some
minor edges of the git conversion instead of tackling this monster in
the middle of the room.

On Tue, Jan 26, 2010 at 08:46:44AM +0000, Albert Astals Cid wrote:
> This has two disadavantages:
>  * Kills the belonging to a group (my app is part of kdeedu so i belong the 
> kdeedu community)
>
of course, somebody had to say exactly that ... too bad that it's bogus.
this is a purely technical decision, and you will regret it if you
overrule it with misapplied social motivations. you can have your
"technologically supported community bonding" in form of a meta package
(most likely git submodules) - something we will need at a higher level
anyway.

>  * Makes it imposible to depend on internal/shared libraries, e.g. some libs 
> in kdebase/workspace/libs are used by kdebase applications but its headers are 
> not installed.
> 
irrelevant. yes, really.
that the modules are split up into separate repositories does not mean
that they *must* be built separately. of course it is would be a
worthwhile aim (and it is rather obviously what troy had in mind for the
end-user packages), but sometimes it plain makes no sense - then one can
simply use the submodule like an svn external.
there is also the option of having internal libraries with installed
headers without api/abi compatibility guarantees. of course these are
harder to dependency-track, but we already have that in form of the new
experimental libs concept.

On Tue, Jan 26, 2010 at 09:56:07AM +0100, Thomas Zander wrote:
> 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.
>
and how is the scm not a technical thing? ;)
anyway, as i said before, the split-up is a prerequisite for a good git
migration, but not the other way round. and there is no way to fix it
afterwards without invalidating the sha1s (which are referenced in
bugzilla, on mailing lists and commit messages).

> 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.
> 
that's certainly true. sounds like we need a plan - how to tackle the
problem, not how to defer it indefinitely.
as i wrote before, the meta-module dependencies could be auto-generated
from the cmake information.
about duplicating cmake files: we might need to actually create separate
library modules for cmake files. and we need some nice infrastructure to
declare the dependencies without adding full-blown FindKFooLib modules
everywhere. a bit like pkg-config (which i think we cannot directly hard
dep on).

> 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.
> 
yes, you can always spin things in such a way that everyone agrees with
you.

> >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'.
> 
yes - in form of a meta package in all sane distros. sounds familiar?

> >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 used.
> 
well, quite frankly, i was recently rather pissed off by that just
configuring kdeutils (to build kcalc and nothing more) required me to
install a full-blown kdepimlibs (or hacking the cmake files). don't you
think that there is something wrong with that?

> 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.
>
this obviously needs a proper technical solution and communication. this
is the hard part, and i'd strongly suggest that those who want the git
migration so badly finally start working on it.