local internal libraries (Was Re: [Fedora-packaging] Conflicts)

Toshio Kuratomi toshio at tiki-lounge.com
Sat Mar 5 15:50:34 UTC 2005

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


More information about the Fedora-packaging mailing list