[pkg-gnupg-maint] transitioning to GnuPG 2.1 in debian
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Tue Apr 14 05:18:06 UTC 2015
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
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:
(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
> 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.)
> 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.
More information about the pkg-gnupg-maint