> Do you really think it's a violation of debian policy that gpgme
> explicitly Depends on the full gnupg suite?
I'm not sure, I suppose policy arbitration is a bit outside of my
skills. I think what's going on goes against the policy, and the current
state prevents any flexibility to handle the s
On Wed, 29 Nov 2017 23:56, d...@fifthhorseman.net said:
> libgpgme provides *no functionality* whatsoever if gpg is not installed.
That is not fully correct. For example in the Outlook plugin we used to
use gpgme just to provide data objects with callback functionality and
to connect to the so-c
Hi Pierre--
Thanks for continuing to engage constructively on this.
The GnuPG packaging split that happened in 2.1.21-4 (and the subsequent
packages added to support things like WKS) does indeed cause more things
to be pulled in by the explicit dependency on the "gnupg" package than
used to be th
> Perhaps we need to consider shipping the same software (the full GnuPG
> suite) in a single, monolithic package. That way, there won't be any
> "new packages" for people to be upset about.
>
> The current package split is designed to try to accomodate people who
> really want a minimalist insta
On Tue 2017-11-28 09:22:48 +0100, Werner Koch wrote:
> On Tue, 28 Nov 2017 00:49, d...@fifthhorseman.net said:
>
>> The fact is, libgpgme explicitly fails in many use cases if gpg-agent or
>> dirmngr are not available. This partial, unpredictable failure is not
>
> It should return an error like N
On Tue, 28 Nov 2017 00:49, d...@fifthhorseman.net said:
> The fact is, libgpgme explicitly fails in many use cases if gpg-agent or
> dirmngr are not available. This partial, unpredictable failure is not
It should return an error like No Agent, No Dirmngr, or No Pinentry. If
not that is a bug ei
On Mon 2017-11-27 13:54:06 +0100, Pierre Ynard wrote:
> I understand your point, and your drive for security is great. However
> to foster the use of free software we should get away from forcing users
> to install unwanted software. Due to the current circumstances, I refuse
> to proceed to any gn
Hello,
> > Many mutt users do not do any secret key operation. I think those
> > who do need to create or setup a private key first - and probably
>
> To foster the use of end to end encryption we should get away from the
> need to install plugins. Encryption should be a core functionality of
> al
On Thu, 23 Nov 2017 13:48, linkfa...@yahoo.fr said:
> Many mutt users do not do any secret key operation. I think those who
> do need to create or setup a private key first - and probably put some
To foster the use of end to end encryption we should get away from the
need to install plugins. Enc
Dear maintainer,
I find myself with the same request as the original reporter; I will try
to answer your questions for myself.
> So let me ask you more about your motivation with this bug report
> here -- are you interested in having fewer packages installed? less
> software total? smaller disk i
Hi RjY--
On Fri 2017-08-18 13:51:29 +0100, RjY wrote:
> As a test I created an empty package to subvert the dependency and see
> if anything breaks. The control file was thus:
>
> Package: no-full-gnupg-install
> Maintainer: RjY
> Architecture: all
> Version: 1
> Depends: gpg (>= 2.1.23-2)
> Reco
RjY wrote:
>It seems in recent unstable the gnupg package has turned into a
>metapackage pulling in the whole gpg suite. Thus the dependency chain
> mutt -> libgpgme11 -> gnupg -> [lots of stuff]
>is pulling in a lot of stuff I don't need.
As a test I created an empty package to subvert the depen
Package: src:gpgme1.0
Version: 1.8.0-3
It seems in recent unstable the gnupg package has turned into a
metapackage pulling in the whole gpg suite. Thus the dependency chain
mutt -> libgpgme11 -> gnupg -> [lots of stuff]
is pulling in a lot of stuff I don't need. I use mutt and don't want to
un
13 matches
Mail list logo
