[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