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

[Daniel Kahn Gillmor]

On Mon 2015-04-13 21:55:29 -0400, NIIBE Yutaka wrote:
> Great.  I think that it is just OK to replace gnupg2 package by GnuPG
> 2.1.

We've already done this in debian experimental.  I am prepared to push
this through to unstable when jessie releases.

> /usr/bin/gpg by GnuPG 2.1 would require some more care, because some
> people in Debian have practice to distinguish gpg and gpg2.

I'm not convinced that we should cater to this distinction.  gpg2 has a
close enough interface to gpg that we should be able to use it in most
places, and i'd really like to avoid having to maintain a critical piece
of infrastructure in a branch that is getting (justifiably) less
attention from upstream.

If there are people who really need the 1.4 branch, and we have the time
and interest to do so, i have no objection to us continuing to maintain
it as /usr/bin/gpg1.

> Some people want to put gnupg binary on their initramfs for LUKS.
> Dependency (and possibly the size) matters, perhaps.  At least,
> documentation for those usages should be updated.

hm, thanks.  initramfs is a good use case to keep in mind.

> Following is not much related to the transition, but a little.  Since
> I think that it's good opportunity, I write my thought.  I talked to
> Eric a bit at LibrePlanet 2015.

I'm sorry i missed that!

> Note: I'm not so good at maintaining Debian packages.  I only know
> basic package maintenance and I don't know well about how to use
> alioth, control at bugs.debian.org and new things like git-buildpackage.

We should have a workday where we talk through the git-buildpackage
workflow and share techniques.

I just registered this for folks who will be at Debconf 15:

  https://summit.debconf.org/debconf15/meeting/194/git-buildpackage-skillshare/

(and i just sent a separate mail about two gnupg-related events i also
proposed for dc15)

> I maintain three GnuPG related packages in Debian: Pth, Scute, and
> Poldi.
>
> After Jessie release, if GnuPG will go to 2.1 series, I'd like to
> orphan Pth package.  It would be good for Scute and Poldi under the
> team maintenance of Debian GnuPG-Maintainers.

I'd have no problem with orphaning pth if we're not using it any more.

But hm, libpth20 is also a dependency for zhcon and genometools-common.
Maybe we can help them transition to npth instead?

> During the development of GnuPG 2.1, Werner developed nPth, which is
> compatible to system pthread library (because it is a thin layer on
> top of system pthread library).  It guarantees only a single thread
> runs.  It's a kind of a hack, but simple and stable enough.  (Then, we
> don't have gnupg-pcsc-wrapper any more in GnuPG 2.1.x.)

sounds reasonable.

> Please note that, in upstreams, Pth, Scute, and Poldi are not active
> any more.
>
> If there will be some demands among its users, I'll work for upstream
> of Scute and Poldi somehow.  But, basically, I don't have an idea to
> keep Pth.

:( This sounds like a frustrating situation to be in (to me), but if
you're OK acting as upstream for scute and poldi, that's great!  I have
no objections to bringing scute and libpam-poldi into the GnuPG
packaging team, if that means you have a bit of backup.

If you want some help in getting scute and poldi packaging into a
functional git-buildpackage arrangement, i'm happy to help.  We should
plan some time to walk through the process.

Regards,

     --dkg