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

NIIBE Yutaka gniibe at fsij.org
Tue Apr 14 01:55:29 UTC 2015


On 04/14/2015 10:05 AM, Daniel Kahn Gillmor wrote:
> Hi Debian GnuPG packagers--
> 
> As jessie releases, I wanted get more discussion going about the
> possibile transition of debian to the GnuPG 2.1 branch as the default
> for /usr/bin/gpg.

Great.  I think that it is just OK to replace gnupg2 package by GnuPG
2.1.  /usr/bin/gpg by GnuPG 2.1 would require some more care, because
some people in Debian have practice to distinguish gpg and gpg2.

> Any objections or complaints about the possibility of considering this
> kind of a change?

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.

> Any thoughts?

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.

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.

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 took over Pth maintenance when I found it was orphaned around 2010.
That's because I had some knowledge for threads implementations (I
joined MIT PThreads in 90's, ported LinuxThreads and NPTL to SuperH
and helped porting them to M32R around 2000).

Pth offers cooperative thread functionality.  In a process, only a
single thread runs, while program is written in a thread programming
style.

Pth is incompatible against system pthread library.  Because of this
Pth incompatibility, we have a helper application 'gnupg-pcsc-wrapper'
in GnuPG 2.0.x for smartcard access.  Since smartcard access by PC/SC
library requires to system pthread library, we have separate
gnupg-pcsc-wrapper program.

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.

Any thought, opinion, suggestion will be appreciated.
-- 



More information about the pkg-gnupg-maint mailing list