[pkg-gnupg-maint] transitioning to GnuPG 2.1 in debian

[Eric Dorland]

* Daniel Kahn Gillmor (dkg at fifthhorseman.net) wrote:
> Hi Debian GnuPG packagers--
[snip] 
> Several different possible approaches (these could be combined):
> 
> == /etc/alternatives ==
> 
>  * make gnupg packages provide /usr/bin/gpg1 and gpgv1, etc, and point to them with /etc/alternatives
>  * make gnupg2 packages conflict with earlier versions of gnupg, and provide the alternatives themselves
>  * set the preferences such that gnupg2 is preferred

I think alternatives are a bit disingenuous, since you can't actually
switch between gpg1 and gpg2.1 easily. You can really only go in the
gpg1 -> gpg2.1 direction.

> == hard cutover ==
> 
>  * the gnupg2 source package could take over the gnupg binary packages
> 
>  * gnupg could start providing gnupg1 binary packages

I think we should do some flavor of hard cutover. I think right after
the release we should:

1. Upload a gnupg2 package with 2.1.
2. Have the gnupg package start providing gpg1 symlinks and Provides.

Then we announce we're moving the gpg package to 2.1 in one or two
months and let people test and perhaps force dependencies on gpg1 for
places where it's scary or we want to control the transition more
directly (dpkg and apt spring to mind). Spend this time fixing bugs,
etc.

3. After those 1 or 2 months, move the current gpg to gpg1 and make
2.1 the new gpg package.
4. Go through any packages still depending on gpg1 and figure out what
needs to happen to move them to newer gpg.

> == metapackage ==
> 
> introduce a metapackage that depends on gnupg2 | gnupg1
> 
> 
> = Concerns =
> 
> here are some things that the gnupg1 packaging currently provides that we ought to be providing in the gnupg2 packages:
> 
>  * udev rules for smartcards
>  * udebs for d-i

udebs probably means udebs for all of the dependencies as well. Any
idea why there's a gnupg udeb and not just a gpgv udeb? Seems like the
installer should only need signature checking.

>  * win32 gpgv
> 
> = Open Questions =
> 
>  * How long will we need to support the 1.4 branch for?

Does anyone need 1.4? Are there any embedded versions of Debian that
prefer it?

>  * What risks does gnupg 2.1 have for the long term?

I guess we need to get commitment that 2.1 will get a "stable" release
in the next 12-18 months, otherwise we'll be supporting something
still vaguely experimental in stretch.

>  * is it OK to drop the 2.0.x branch entirely?

I'm OK with it :)

>  * What is the time frame for this change?  (can we complete the
> transition in stretch?)

I think it's reasonable that we can make this happen for stretch,
though I guess it will depend on bugs we find.

-- 
Eric Dorland <eric at kuroneko.ca>
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20150414/1281d0ae/attachment.sig>