Reopen a request for gpgme in Core

[Michael Schwendt]

On Fri, 7 Jan 2005 08:48:10 +0100, Michael Schwendt wrote:

> On Thu, 6 Jan 2005 21:48:44 -0600, Dennis Gilmore wrote:
> 
> > > Among the things to examine are:
> > >
> > >  * Dependencies on GPGME 0.4.x: gpa, elmo
> > >  * Dependencies on GPGME 0.3.x: cryptplug, seahorse, sylpheed-claws
> > >    (seahorse is very old, but pcomptom said maybe he will continue it)
> > >  * In which way or whether cryptplug uses gpgsm?
> > >  * Is cryptplug of any use in FC3?
> >
> > AFAIK cryptplug is no longer of use  in FC3  kmail in kde 3.3 has the 
> > functionality added i think mutt may have used it to sign mails also  but i 
> > dont think  there was ever a client patch to take advantage it.
>  
> Good. Then the only dependency on gpgme 0.3.x is Sylpheed-claws (well,
> and Sylpheed in Fedora Core for people like me who rebuild it with
> GPGME privately).
> 
> Has anyone any objections against rebuilding GPGME 0.3.x without
> support for GPGSM? That would enable us to get rid of the dependency
> on newpg (via /usr/bin/gpgsm). It would also make libksba 0.4.x
> obsolete, and upgradable to libksba 0.9.x as needed by GNUPG 2. The
> build dependency on gpgsm could be dropped anyway, and the
> install-time dependency would no longer be needed. Does any package
> exist which would use GPGME 0.3.x + GPGSM and is not included in
> Extras?
> 
> Left would be GPGME 0.4.x as used by elmo and gpa. Neither one uses
> GPGSM either, so GPGME 0.4.x could also be rebuilt without gpgsm
> dependency. Then, both gpa and elmo build against GPGME 1.0.x, so no
> urgent need to keep GPGME 0.4.x, not even as gpgme04 package.
> 
> Still to check: gpa and elmo build with GPGME 1.0.x, but do they work
> correctly?

As a status update here:

  elmo : "project was closed" 2005-01-06 according to the web site

  gpgme03 : can stay until Sylpheed-claws/Sylpheed are ported
            to GPGME 1.0 API

  gpgme : as mentioned above, the 0.4.x version is only used by "elmo"
          and "gpa", and both build with GPGME 1.0 API - we could
          upgrade it and need not keep a gpgme04 package

  cryptplug : not used anymore (it depends on gpgme03)

  newpg : temporary project, obsolete with GnuPG 2, none of our
          packages _really_ requires its functionality through GPGME

  libksba : 0.4.x version only used by newpg - we could upgrade to
            the 0.9.x version used by GnuPG 2

Conclusively:

If we continued with trying to add a GnuPG 2 pre-release into Extras, we
would upgrade

  libassuan
  libksba
  gpgme (0.4.x to 1.0.x)

and add

  gnupg2 (which would be parallel-installable with gnupg)
  dirmngr

and we would need to decide on which features to include, since the
current candidates in fedora.us QA queue also include smartcard
functionality. GnuPG 2, however, is something which will likely be
included in Fedora Core some day. Hence I feel we should avoid that
future core packages of GnuPG 2 contain less features.

What's current procedure with regard to such coordination between Core
and Extras?