[pkg-gnupg-maint] Bug#1023601: Bug#1023601: libgpgme-dev: removal of gpgme-config breaks the build of software relying on it

[Daniel Kahn Gillmor]

Control: severity 1023601 important
Control: reassign 1023601 src:libgpg-error 1.46-1
Control: affects 1023601 + src:gpgme1.0 src:rust-libgpg-error-sys src:rust-libgpgme-sys

Thanks Vincent for identifying the confusing and misdirected
documentation upstream, and thanks Andreas for triaging this and for
filing both reports upstream related to the missing documentation.

I agree that this is annoying, but it seems better to me to rip the
band-aid off now, and try to get the ecosystem to move as needed.

I'm reassigning the issue to libgpg-error, because upstream gpgme only
installs gpgme-config when gpg-error-config is present, so to "fix" the
issue in gpgme, we'd need to change how we distribute libgpg-error (to
force the non-default shipping of gpg-error-config) and then rebuild
gpgme against the updated while shipping the appropriate buildscripts.

I'd really prefer to stick with upstream's defaults here: they've moved
to pkg-config as the expected/default cross-platform build process, and
we should encourage the ecosystem to move with that.  I also happen to
agree with upstream that commonly shared, declarative packaging
practices like pkg-config are a safer and more sensible approach to
build configuration than executing arbitrary code for each dependency.

Vincent wrote:

> So, if I understand correctly, either gpgme-config should be based on
> gpgrt-config rather than gpg-error-config (this should be an upstream
> change), or gpg-error-config should be re-added as suggested.

fwiw, upstream has indicated that gpgrt-config is an "internal"
interface, so this is not something that should be used explicitly by
external dependencies.

Vincent Lefevre wrote:
> Remember that libgpgme-dev is not just useful to build Debian
> packages, but also to build software that is not part of Debian.

Vincent is right about this, but we're doing those downstream projects
no favors if we encourage them to use an internal interface that
upstream isn't installing by default.  If upstream wants users to move
to the more modern interface, which has already been supported for
years, we should help that happen.

> In any case, a decision has to be made: either consider that the
> change is too early, and the next Debian release should have this file
> (in this case, the RC bug is justified), or consider that it is up to
> other software to be updated (or users to find a workaround), in which
> case, things should at least properly documented: the GPGME manual
> currently says:

I've reclassified this bug to severity: important because i think that
we should try to go with the upstream default preferences.  In the event
that a significant amount of unrelated debian-internal software is
broken by these change, i'm willing to consider a reversion to the
changes in libgpg-error, but at the moment the only remaining packages
i've seen are:

 rust-libgpg-error-sys
 rust-libgpgme-sys
 mutt

The first two packages are not at all unrelated packages, they're Rust
wrappers for libraries that GnuPG wants to expose externally, and have
already been fixed upstream with new releases that use GnuPG's expected
mechanisms for configuration (iiuc their inclusion into debian is held
up by the version of cargo that they rely on, which should be landing
shortly).

And mutt is already handled thanks to Kevin and Vincent's work on
#1023599.  This kind of ecosystem simplification and cleanup is exactly
the sort of thing that Debian should be putting its weight behind.

> BTW, after all, the use of gpgrt-config might not be user-friendly
> in an interactive shell (as opposed to a configure.ac file).

The most user-friendly solution in an interactive shell is pkg-config,
which doesn't require a user to learn a new syntax or convention for
each library.  pkg-config also happens to make cross-building more
straightforward, which is (rightly) a longstanding concern for debian.

The more we get reverse dependencies to switch over to this kind of
configuration system, the better.

All the best,

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20221114/47a06c89/attachment.sig>