kdegraphicslibs (Was: libkdcraw api compatibility?)

[Albert Astals Cid]

El Dimecres, 21 de novembre de 2012, a les 14:25:22, Allen Winter va escriure:
> 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.

Did we? Then why did we install libkdegames headers back then?

And calligra uses marble libs, an calligra uses okular libs, not sure this 
policy really makes much sense to be honest.

> i.e we can't have kphotoalbum dependent on libkdcraw from kdegraphics

Why not? What you are suggesting is:
 a) Move libkdcraw out of the SC since their developers have stated clearly 
they don't want to maintain BC
 b) Move kphotoalbum to the SC so it can use libkdcraw
 c) Make kphotoalbum reimplement libkdcraw functionality

> I think this is still a good policy.

I don't think so, that's like killing the library, why would you develop a 
library inside a KDE repo if only people on the same repo can use it?

> 
> 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.

Sure, that would be ideal, but do the developers of these libraries want to 
enforce that ABI/API restrictions? From my recollection the answer is no.

Maybe we should ask again :-)

kdegraphicslibs guys, are you here?

Cheers,
  Albert

> 
> 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.
> 
> > And I think this is a fair request, if they respect soname bumps, and
> > regular versioning stuff why should we force them to do so?
> > 
> > Cheers,
> > 
> >   Albert
> >   
> > > On Wednesday 21 November 2012 08:54:20 AM Rex Dieter wrote:
> > > > Andreas K. Huettel wrote:
> > > > > it seems like there are api-incompatible changes in libkdcraw-4.9.80
> > > > > (compared to 4.9.x).
> > > > 
> > > > ...
> > > > 
> > > > > No problem inside KDE proper, and I also know that digikam-3_betaX
> > > > > and
> > > > > kipi- plugins-3_betaX is fixed. However... Are there any other known
> > > > > third-party consumers for that?
> > > > 
> > > > kphotoalbum uses libkdcraw
> > > > 
> > > > On a similar note, libkipi also had changes that breaks
> > > > kamoso, https://bugs.kde.org/show_bug.cgi?id=307147
> > > > and
> > > > kphotoalbum, https://bugs.kde.org/show_bug.cgi?id=307148
> > > > 
> > > > -- rex
> > > > 
> > > > _______________________________________________
> > > > release-team mailing list
> > > > release-team at kde.org
> > > > https://mail.kde.org/mailman/listinfo/release-team
> > > 
> > > _______________________________________________
> > > release-team mailing list
> > > release-team at kde.org
> > > https://mail.kde.org/mailman/listinfo/release-team
> > 
> > _______________________________________________
> > release-team mailing list
> > release-team at kde.org
> > https://mail.kde.org/mailman/listinfo/release-team
> 
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team