Re: the way to enigmail: gnupg 2.1 backport considerations

[Antoine Beaupré <anarcat@orangeseeds.org>]

Hi,

As I'm running out of time to work on this problem for the month, I
figured I would at least try to wrap up the conversation we had on the
topic here so we can find a solution to move forward on.

The current situation is that I have a backport of GnuPG 2.1 available
for testing here:

    https://people.debian.org/~anarcat/debian/jessie-lts/

It should work with the libraries from jessie-backports, and I haven't
heard any negative (or positive) feedback on the build, so I'm going
under the assertion that it doesn't cause too much trouble.

The blocker is it depends on those four jessie-backports libraries:

  * libassuan (2.1 -> 2.4)
  * libgcrypt20 (1.6 -> 1.7)
  * libgpg-error (1.17 -> 1.26)
  * npth (1.0 -> 1.3)

All four libraries are GnuPG-specific libraries that GnuPG 1.4 does
*not* currently use. They *are*, however, used by GPGME so that means
they are (transitively) linked into any package linking against libgpgme
(and there are quite a few of those). I do hope that GPGME would
insulate consumers from such changes however.

Updating gpg through backports is not possible: -backports is closed and
will be archived soon.

I have therefore proposed to simply ship the four libraries backports in
jessie directly. The concern is that those library updates are not
"bugfix-only" releases and might not be suitable fo sur updates.

An alternative approach would be to statically link gnupg2 against those
libraries or ship them as private copies, possibly as a separate binary
package, that would remain as cruft that a stretch upgrade would 'apt
autoremove'.

So that's the state of affairs. How do we move forward?

I've unassigned myself the Enigmail package to allow others to take a
shot at this in the next two weeks.

Have fun!

A.

-- 
You can't conquer a free man; the most you can do is kill him.
                       -  Robert A. Heinlein