Package: libgpgmepp-dev Version: 1.18.0-4.1+b2 Severity: important Ahoy,
While investigating adding support for gpgsm via GPGME to Poppler for PDF
signing, I found that the dependency chain isn't right. One can see that
/usr/include/gpgme++/error.h tries to include <gpg-error.h> from
libgpg-error-dev unconditionally, and since other gpgme++ headers include
<gpgme++/error.h>, this quickly becomes a problem if <gpg-error.h> cannot be
found. It seems like a happy coincidence that reverse dependencies aren't
struggling with this problem: they all seem to pull libgpg-error-dev in for
other reasons or to work around this. APT affirms that the dependency is not
pulled in, not even transitively:
$ apt-get satisfy -o Debug::pkgDepCache::Marker=true -s "libgpgmepp-dev"
"Conflicts: libgpg-error-dev"
MarkInstall satisfy:command-line:amd64 < none -> 1 @un puN > FU=1
MarkInstall libgpgmepp-dev:amd64 < 1.23.2-1 @ii pK NPb IPb > FU=0
MarkInstall libgpgmepp6t64:amd64 < 1.23.2-1 @ii pK > FU=0
MarkInstall libc6:amd64 < 2.39-6 @ii pK > FU=0
MarkInstall libgcc-s1:amd64 < 14.2.0-1 @ii pK > FU=0
MarkInstall gcc-14-base:amd64 < 14.2.0-1 @ii pK > FU=0
MarkInstall libgpgme11t64:amd64 < 1.23.2-1 @ii pK NPb IPb > FU=0
MarkInstall libassuan0:amd64 < 2.5.6-1+b1 @ii pK > FU=0
MarkInstall libgpg-error0:amd64 < 1.50-3 @ii pK NPb IPb > FU=0
MarkInstall libstdc++6:amd64 < 14.2.0-1 @ii pK > FU=0
MarkDelete satisfy:command-line:amd64 < none -> 1 @un pumN > FU=1
This affects at least the GPGME versions in both unstable and experimental, but
since Poppler requires the version in experimental (>= 1.19.0) anyway, there's
hardly any reason to bother applying this to unstable. I expect that the
version just uploaded to experimental will likely make it into Trixie, but let
me know if I'm wrong about that. In any case there is no hurry.
Thanks,
John
--
🌐 Homepage https://johnscott.me
signature.asc
Description: This is a digitally signed message part
smime.p7s
Description: S/MIME cryptographic signature
