KDE Platform Profiles

[Alexander Neundorf]

On Monday 26 April 2010, Kevin Ottens wrote:
> On Monday 12 April 2010 21:40:46 Alexander Neundorf wrote:
> > On Monday 12 April 2010, Kevin Ottens wrote:
> > > Gooooood (not-so-)morning(-anymore) kde-core-devel!
> >
> > ...
> >
> > > Then, what becomes important is to streamline the dependencies within
> > > the KDE Platform so that less storage, memory and bandwidth consumption
> > > is generated by pulling a KDE application. That also means that we need
> > > to clearly communicate about the packages that should be split from
> > > kdelibs and friends. Instead of a single kdelibs binary package, we
> > > need one per kdelibs submodule (kdecore, kdeui, solid...).
> >
> > Ok, this part means some work for the buildsystem.
> >
> > Right now, in any KDE4 application, you do a find_package(KDE4) and if
> > that succeeds you can be sure that everything is there.
> > The only optional library right now is nepomuk (or isn't it optional ???)
> > and kdefakes, kdesu and kpty exist only under UNIX.
> >
> > If kdelibs can be installed in a modular way, this changes somewhat.
>
> I'm just replying to that as I think maybe I've been unclear on this point.
> I really meant about *binary packages* so at *runtime* maybe not all of
> kdelibs is here. That's why it's really something related to how the
> packagers do their job (to make sure a given app/lib has all its runtime
> dependencies in place).

This would mean that there'll be binary packages like liblkhtml, libkatepart, 
libsolid. And additionally to those split packages, there will be _one_ 
kdelibs-devel package (i.e. not a libkhtml-devel, libkatepart-devel and 
libsolid-devel package).

Does that sound reasonable for the packagers ?

Personally I would have expected for each package without devel stuff an 
accompanying package with the devel stuff for each.

Alex