[ moving (and setting m-f-t) to pkg-gnupg-maint, which is a more appropriate forum for this discussion. for folks just joining us for the backlog, please see https://bugs.debian.org/873499 ]
On Mon 2017-09-11 16:56:39 +0200, Yuri D'Elia wrote:
> On Mon, Sep 11 2017, Daniel Kahn Gillmor wrote:
>> On Mon 2017-09-11 14:28:29 +0200, Yuri D'Elia wrote:
>>> I'd rather go for this route, and recommend gpg-agent from gpg,
>>
>> gpg already Recommends: gnupg, which itself Depends: gpg-agent.
>
> I'd recommend gpg-agent, and suggest gnupg instead.
why? upstream recommends shipping all the binaries in a single package
as the standard deployment. I'm trying to meet them halfway here.
The definition of Recommends is:
This declares a strong, but not absolute, dependency.
The Recommends field should list packages that would be found together with
this one in all but unusual installations.
https://www.debian.org/doc/debian-policy/index.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends
Upstream's preference is to have all the binaries installed, and gpg
itself is never even tested upstream without having all the other
binaries available.
I'm willing to keep the split in debian to support narrowly-scoped, tiny
systems administered by technically-competent people. But we've got
enough issues to focus on without encouraging full-blown desktop systems
that have gpg fail because of missing dependenencies, which is what i
think would happen if we moved the rest of the suite out of Recommends.
Do you think that wouldn't happen?
>> This package contains /usr/bin/gpg itself, and is useful on its own
>> only for public key operations (encryption, signature verification,
>> listing OpenPGP certificates, etc). If you want full capabilities
>> (including secret key operations, network access, etc), please
>> install the "gnupg" package, which pulls in the full suite of tools.
>
> This package contains /usr/bin/gpg itself, and is useful on its own only
> for public key operations (encryption, signature verification, listing
> OpenPGP certificates, etc). For operations involving secret keys and
> passphrases, gpg-agent is also required. If you want full capabilities
> (network access, X.509 and CMS and all other command line utilities),
> please install the "gnupg" package, which pulls in the full suite of
> tools.
Thanks for the suggested text. Can you explain why the package
Description: should call out secret key use separately from, say,
network access, or other modules of the suite?
> I don't oppose the idea of a separated process with different
> capabilities. This is fine for using gpg as a daemon for interactive
> usage.
gpg is not a daemon, it's a one-shot process, which knows how to talk to
various system daemons.
> But on the other side, when all you want to do is use gpg in a batch
> script and it fed stuff which is already on disk, these separate
> processes do hardly anything useful.
they most certainly do -- for just one example, in a batch script where
gpg is invoked a number of times, the long-running dirmngr process can
cache knowledge about the network between invocations of gpg.
--dkg
signature.asc
Description: PGP signature
