Preferred packaging of kdevplatform [was: Re: kdepimlibs compile requirements -- boost]

[Matt Rogers]

On Monday 02 July 2007 18:05, Andreas Pakulat wrote:
> Moving this over to kdevelop list.
>
> On 03.07.07 01:39:17, Andras Mantia wrote:
> > On Monday 02 July 2007, Andreas Pakulat wrote:
> > > > Otherwise we will end with binary packages for kdevplatform which
> > > > will depend on boost. I'm sure I don't want to see that.
> > >
> > > Thats wrong. The plugins of the platform need to packaged separately
> > > and thus only those plugin package(s) would have a dependecy on
> > > boost. Apart from that its (IIRC) just 2 boost libs that are
> > > installed and I think quite some users might have installed them
> > > anyway.
> >
> > This is the first time I heard that the platform plugins should be
> > packaged separately. Is this documented so packagers actually know it
> > that this is what we want?
>
> No.
>

Who said that the platform plugins would be packaged separately? My idea was 
to keep them all bundled together. Yes, this would mean that it would depend 
on boost and GNU common c++ if you wanted that plugin available to you.

> > Is this what we want?
>
> I don't know. Its just something I actually think makes sense. Maybe not
> all plugins would be in a separate package, for example a kdevplatform
> application without outputview plugin or projectmanagerview is pretty
> useless. OTOH stuff like svn,cvs and teamwork are things that are in
> platform so not every app using the platform has to "reinvent" them or
> depend on another app just for these plugins. So I'm thinking we should
> tell packagers a plugin list that needs to be installed always and the
> rest can be packaged separately and the user can decide wether he wants
> them or not.
>
> > I actually thought that kdevplatform is there as it is just because
> > everything inside there is useful - to not say mandatory - for every
> > application using the platform interface and libraries. So it actually
> > makes sense to provide one package as it is.
>
> See above, I'd still split it into mandatory and optional-but-useful
> parts.
>
> Andreas

We will package a single source tarball. Let the distributions figure out how 
they want to split the packages.
-- 
Matt