On Sat, Mar 05, 2005 at 03:02:18AM +0100, Michael Schwendt wrote:
>
> Last time I looked, kmail was built with an internal GPGME 0.4.4 copy,
> and its OpenPGP features worked for me.
>
> $ rpmlsv kdepim |grep -i gpgme
> -rwxr-xr-x root root 787 /usr/lib/libgpgme++.la
> lrwxrwxrwx root root 19 /usr/lib/libgpgme++.so.0
> -rwxr-xr-x root root 228304 /usr/lib/libgpgme++.so.0.0.0
> -rwxr-xr-x root root 906 /usr/lib/libqgpgme.la
> lrwxrwxrwx root root 18 /usr/lib/libqgpgme.so.0
> -rwxr-xr-x root root 20048 /usr/lib/libqgpgme.so.0.0.0
> drwxr-xr-x root root 0 /usr/share/doc/HTML/en/kdepim-apidocs/libkdenetwork/qgpgme
> drwxr-xr-x root root 0 /usr/share/doc/HTML/en/kdepim-apidocs/libkdenetwork/qgpgme/html
Oops. I've been misreading bug number 136533, which is actually asking only
for Certificate Handling, not all OpenPGP support.
This brings up a new question, though. What are good justifications for
using an internal library vs creating a system one? In this case, I think
the internal library solves these problems:
1) Allows Core to be updated with a feature enhanced (gnuPG2) version from
Extras.
2) Brings gpgme support to kmail without fussing with another package that
is presently only needed by kmail.
A) Doesn't apply in this case, but could help resolve version conflicts.
(Example is sylpheed/claws gpgme requirements. Because claws requires
gpgme03 to compile, creating a gpgme03 package is not enough; we also
need the -devel package which conflicts with gpgme-1.0. Compiling
against an internal gpgme03 would solve this.)
But it has these problems:
1) Increased size for someone who installs gpgme from Extras.
A) Extras packages can use gpgme. Mixed bag as Core's gpgme would be
built without S/MIME.
2) kmail does not get S/MIME features when gpgme from Extras is installed.
3) kmail does not get updated bugfixes/security fixes unless the kdepim
packager updates to new gpgme versions (In this case, gpgme is version
1.0.2 and kmail is using 0.9.. only four versions out of date.)
Here are some ideas for guidelines:
Applications should have local, internal copies of libraries if:
1) It is the best way to resolve a version conflict with a libary update
that requires API changes because the two versions do not have parallel
installable devel files (sylpheed-claws).
2) The application is in Core and the library would conflict with another
library package in Extras that cannot move to Core. Reasons for this
could include:
A) Library in Extras is deemed unstable for inclusion in Core but a
feature reduced version/other version will work. (kdepim/kmail)
When a package uses a local, internal library it should:
1) Be listed somewhere (fedoraproject.org/wiki page?) as using a local,
internal version of the library with version and reason.
Open question:
How much burden does the maintainer of the package with a local, internal
library carry for updating the internal library? Who else would carry it if
not the maintainer of the package? Can automated tools to tell of updates
to the main library package help the package maintainer?
-Toshio
