kdegraphicslibs (Was: libkdcraw api compatibility?)

[Albert Astals Cid]

El Dimecres, 21 de novembre de 2012, a les 20:31:13, Sebastian Kügler va 
escriure:
> On Wednesday, November 21, 2012 14:25:22 Allen Winter wrote:
> > On Wednesday 21 November 2012 07:33:28 PM Albert Astals Cid wrote:
> > > El Dimecres, 21 de novembre de 2012, a les 11:38:09, Allen Winter va
> 
> escriure:
> > > > Sounds like we need a new module for graphics libraries.
> > > > Along the lines of kdepimlibs, but for graphics
> > > 
> > > Why? The people developing those libraries don't want to maintain the
> > > ABI/API  of these libs during all the life of 4.x
> > 
> > We have (had) a policy that no application-module-library should used
> > by applications outside that module.
> > 
> > i.e we can't have kphotoalbum dependent on libkdcraw from kdegraphics
> > 
> > I think this is still a good policy.
> > 
> > But we know that digikam, kphotoalbum, etc. does rely on libs from
> > kdegraphics.
> > 
> > If we put such libs in a new module called kdegraphicslibs and enforce the
> > ABI/API restrictions there, then we can eliminate these problems in the
> > future.
> > 
> > I think kdepimlibs has proven this to be a successful strategy.
> > Lots of non-kdepim stuff depends on kdepimlibs and we haven't had
> > ABI/API complaints problems from that combination in a long time.
> > 
> > Some libraries are widely used and can conceptually be thought of as core
> > libs. Perhaps libkdcraw is such a library.
> 
> One question to consider is wether this split should be done before
> Frameworks5, or as part of it. I think the Frameworks5 approach (so putting
> kdcraw, libkipi into separate packages and ship them as separate frameworks.

We do that already.

Cheers,
  Albert

> 
> In any case, we should commit to binary compatibility similar to kdelibs for
> these, if possible, but that depends on their authors. (It's just as broken
> a process right now, however, from a deployment point of view.)
> 
> Cheers,