modular kdelibs: packagers' view

[Scott Kitterman]

On Sunday, June 05, 2011 08:16:39 AM Sebastian Kügler wrote:
> Hi all,
> 
> I'm writing this email from the Platform11 sprint in Randa, and I'd like to
> collect input how we can get the different needs of developers and
> packagers together.
> 
> Let me quickly outline the situation. There has been a trend and desire to
> ship kdelibs (and other parts of our development platform, I'm just writing
> kdelibs here for convenience) as separate libraries, the reasons for this
> are:
> 
>  * can be individually consumed by 3rd party developers, no either or
> decision for kdelibs, helps 3rd party adoption
>  * kdelibs' purpose is not anymore just desktop, mobile use cases become
> more important, more modularity helps to create leaner systems
> 
> If we end up doing this, it has two important ramifications:
> 
>  * More individual packages, might create extra work for packagers,
> depending on their tools
>  * Change in package's structures
> 
> While the consequences for developers can be kept rather low, it *will*
> mean some restructuring of existing packages.
> 
> I see a couple of things we can do here:
> 
>  * Provide "traditional" tarballs, leading to relatively little disruption,
>    but means duplication as we provide different sets of tarballs that
>    overlap, might be more confusing than worth it
> 
>  * Do the split once, try to prevent the git migration mess where we've
>    clearly not thought through the ramifications for release management,
> which lead to much confusion and frustration among packagers
> 
> As we haven't taken any firm decisions, I'd like to invite input from you,
> to see how we can accommodate your workflows and keep the extra work for
> those packaging low. Please do keep in mind that those changes are
> necessary for KDE to move on, since modularizing our platform is an
> entirely useless effort, if those changes aren't reflected in the form
> they end up on most developers' machines.
> 
> Thanks for your input already. Also please don't wait too long with your
> feedback, since it's essential for ongoing discussions here at Platform11.
> I will be collecting the input and taking it into the discussions going on
> here. (There are some packagers present, but obviously we should give
> everyone the chance to provide input.)

This is mostly duplicative of what I said re the git migration, but here you 
go ...

I would prefer the split once approach.  I don't want to be at a disdavantage 
in terms of modularity because we're building distro packages instead of 
direct source builds, but I want the split to be thought out in advance so we 
only have to do the work of splitting once (modulo I know there will be bugs, 
no one is perfect).

For kdelibs, it is essential that the interfaces that will be newly exposed be 
managed properly.  By there will be interfaces that are now private within 
kdelibs that will be exposed to the public.  They have to be managed with the 
same compatibliity guarantees that currently apply to kdelibs.  If not it'll 
be a mess and (IMO) seriously interfere with achieving the goals of splitting 
it up.

Scott K