[Kde-graphics-devel] libkface
Gilles Caulier
caulier.gilles at gmail.com
Thu Sep 18 20:31:08 UTC 2014
2014-09-18 21:39 GMT+02:00 Albert Astals Cid <aacid at kde.org>:
> El Dijous, 18 de setembre de 2014, a les 07:01:32, Gilles Caulier va escriure:
>> 2014-09-17 20:36 GMT+02:00 Albert Astals Cid <aacid at kde.org>:
>> > El Dimecres, 17 de setembre de 2014, a les 15:07:59, Tobias Leupold va
>> >
>> > escriure:
>> >> Hi list!
>> >>
>> >> I'm from the KPhotoAlbum project. We recently introduced support for face
>> >> detection and face recognition using libkface. Likely, this will be a
>> >> part
>> >> of the next release. Actually, we are the first project apart from
>> >> Digikam
>> >> (who initiated and maintain libkface) to use libkface.
>> >>
>> >> This leads to a problem: at the moment, libkface is distributed with the
>> >> Digikam sources. There's an own git repository for the lib's sources in
>> >> the
>> >> KDE repositories, but there's no own release.
>> >>
>> >> Some distributors (e. g. Gentoo) have an own package for libkface
>> >> nevertheless, others don't (e. g. Debian). So, at the moment, we would
>> >> have
>> >> to include libkface in our sources, as Digikam does (which would lead to
>> >> collisions if both KPA and Digikam would be installed and is perhaps not
>> >> a
>> >> good idea) or we would have to pull the full Digikam package as a
>> >> dependency if the user wants libkface support.
>> >>
>> >> Both "solutions" don't seem to be nice.
>> >>
>> >> Thus, Gilles Caulier from Digikam suggested to move libkface into
>> >> kdegraphics/libs, so that it will be included into the normal KDE release
>> >> cycle and will be independent of Digikam, cf. the discussion on the
>> >> Digikam
>> >> mailing list:
>> >>
>> >> http://mail.kde.org/pipermail/digikam-devel/2014-September/075737.html
>> >>
>> >> He said I had to ask the kdegraphics mailing list if the admins would
>> >> also
>> >> agree to do so.
>> >>
>> >> So what do you think?
>> >
>> > I don't think adding to kdegraphics/libs is needed, you can just make
>> > independent releases from it's current living position at extragear/libs,
>> > no?
>> digiKam team will not made an independent release of this library.
>
> Collaboration \o/ oh :-/
Excuse me to shared and maintained this library. If this not enough...
>
>> We have do it in the past with libkipi, libkexiv2, and libkdcraw, and
>> it's the hell and time consuming. This is why these libs are hosted in
>> kdegraphics/libs since a while.
>
> And we've had countless problems with them because you kept changing them
> ignoring all the rules we have for libs in kdegraphics/libs
Ah, which one exactly ?
We take a care about BC and KDE release plan.
> and shipping them
> as part of your "digikam SC"
Not totally true. There is a flag in digiKam SC root cmake file to
exclude libkipi, libkexiv2, and libkdcraw of compilation and use
system based libs. This one is used by packagers.
>
>> If the same rules about libkface can be done to share publicly this
>> API with other KDE applications, this will be perfect and homogeneous.
>
> Anyway this is not the place to ask for a new module to be added to a stable
> release, i'd say kde-core-devel is or release-team.
If to include libkface in kdegraphics/libs is too problematic (as i
suspect), we can do better for KF5 : drop libkexiv2, libkipi, and
libkdcraw from kdegraphics and that all. Like this, you can be sure
that all will be clean from my side in kdegraphic/libs...
Gilles
More information about the Kde-graphics-devel
mailing list