[Kde-scm-interest] [Proposal] Package splitting with thin meta-repos

[Ian Monroe]

On Sat, Jan 30, 2010 at 5:18 PM, Albert Astals Cid <aacid at kde.org> wrote:
> A Dissabte, 30 de gener de 2010, Thiago Macieira va escriure:
>> Em Sábado 30. Janeiro 2010, às 23.22.56, Albert Astals Cid escreveu:
>> > A Dissabte, 30 de gener de 2010, Thiago Macieira va escriure:
>> > > Em Sábado 30. Janeiro 2010, às 16.34.27, Oswald Buddenhagen escreveu:
>> > > > > You don't link to applications. You link to libraries.
>> > > > >
>> > > > > This includes plugins: plugins link to libraries.
>> > > >
>> > > > uhm ... so?
>> > > > - the application needs to provide headers which define the interface
>> > > > - the application may provide an internal library to link against
>> > >
>> > > It's not internal. It's a public library, with installed headers.
>> > >
>> > > It is so because the hypothetical plugin we have in mind here comes
>> > > from a separate module.
>> >
>> > So you mean i have to put libokularcore in a different git repo than
>> > okular if i want it to be possible for someone else to write okular
>> > plugins (aka supporting other formats)?
>>
>> Yes, I was.
>
> FWIW i think this is a bad idea.

Yea. The issue is that the biggest modules (kdelibs, kofficeand
kdebase) which would ostensibly have the most to gain from being split
up, are also the ones which have the most reason to stay as one unit.
For instance plasma code is often moving around withing kdebase.
KOffice has rather complicated dependencies I believe, and their
community explicitly doesn't want to split it up.

Packages like kdegames and kdeedu have the least to gain from
splitting up since they are small, but it would also not be a big deal
if they did. There already is a 'libkdegames' (which would fit nicely
into Thiago's idea), and each game is otherwise fairly self-contained
with probably no complicated cross-dependencies.

So assuming we have good tools to clone and tag a 'kdegames' or a
'kdeedu' meta-repo, I really don't see any reason to keep them whole.
But not a whole lot of reason to split apart, especially with some new
cmake features that make building individual apps easier.

I guess my point is that it doesn't matter much. :)

Ian