kdegraphicslibs (Was: libkdcraw api compatibility?)

[Sebastian Kügler]

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.

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,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9