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
signature.asc
Description: PGP signature