It's not possible to block gnupg-2 when something else (app-crypt/seahorse) depends on gpgme because the ebuild depends on >=gnupg-1.9.20. The application itself only requires >=gnupg-1.2.2. Reproducible: Always Steps to Reproduce:
*** This bug has been marked as a duplicate of bug 164523 ***
I don't see how this is a duplicate - I'm not using gnupg-2.
(In reply to comment #2) > I don't see how this is a duplicate - I'm not using gnupg-2. > Well, the bug discusses the seahorse issue, including members of the crypto team. Wrt. not using GnuPG 2, my bet is that the crypto team set the dependency in GPGME purposefully, since maintenance-wise the best path is to fade out GnuPG 1.x support as quick as possible.
It's necessary to explicitly mask gnupg-2, so I don't think there's any problem with allowing gpgme to use gnupg-1. A USE flag on gnome to stop it including seahorse would work too...
kde-libs/kdepimlibs also depends on gpgme. You need to fix this bug that makes it impossible to use gnupg-1 without having to make repeated ebuild changes after every rsync. gpgme does not depend on gnupg-2.
I don't use =app-crypt/gnupg-1.4*, but I don't have objections to allowing this version in dependencies of app-crypt/gnupg.
(In reply to comment #6) > I don't use =app-crypt/gnupg-1.4*, but I don't have objections to allowing this > version in dependencies of app-crypt/gnupg. I can't remember why the dependency was put in and there seems to be evidence that gpgme can work with gnupg-1.4 so I'm in favour of reducing the dependency too.
Fixed in app-crypt/gpgme-1.1.8-r1.