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?
