[Digikam-devel] KPhotoAlbum is using libkface now

Tobias Leupold tobias.leupold at web.de
Wed Sep 17 12:54:07 BST 2014


> 1/ move libkface into kdegraphics/libs, as libkipi, libkexiv2, and
> libkdcraw. Release is done with KDE. This can be a good way since code
> is in a better stage now.
I think this would be the nicest solution!

> 2/ do as digiKam : include libkface as 3rdparty lib to kphotoalbum.
> Not the best but this simplify release plan. Look how it's done in
> digiKam. We have a super repository with scripts that we run to check
> 3rd party code at release time. It's done automatically.
I'll have to ask the "big" KPA developers if this would be possible to do. But 
your first solution sounds a lot better to me.

I just thought of the Gentoo way. We have a single libkface ebuild, which 
takes the Digikam sources and only builds and installs libkface. Digikam 
itself also depends on this ebuild, so if you install it, Digikam will be 
built without libkface (after building libkface itself, of course).

So what I have been thinking of, of course for Gentoo, is a USE-Flag telling 
if we want or don't want libkface support (the implementation in KPA is 
optional). So if you want it, KPA simply pulls libkface and when it's there, 
the face detection/recognition functionality will be built.

I don't know if this would work analogously for other distributions.

But what would happen if we packaged libkface, if you install both Digikam and 
KPA? Wouldn't we get collisions?

I really think a separate release for libkface would be the way better 
solution ... especially, if it could be done automatically, as you write above 
(sorry, I'm a very new KDE dev, so I don't know how this all works yet ;-)



More information about the Digikam-devel mailing list