[pkg-gnupg-maint] Bug#933713: libgpg-error-dev: make package fit for cross development

[Francois Gouget]

On Wed, 12 Feb 2020, Daniel Kahn Gillmor wrote:

> On Tue 2020-01-28 13:01:04 +0100, Francois Gouget wrote:
[...]
> > So I think it is reasonable to stop shipping gpg-error-config, just like
> > FreeType stopped shipping freetype-config to become multiarch-compatible.
> 
> I agree that upstream's preferred configuration mechanism
> (gpg-error-config) is not well-suited for the modern multiarch world.

But is gpg-error-config upstream's _preferred_ configuration mechanism 
or merely the legacy one?


> That said, I'm not convinced that removal of upstream's preferred 
> configuration mechanism in debian is a great idea. Have you 
> successfully built (for example) libgcrypt or the other reverse 
> dependencies in debian against such a modified package?

I did not try. But any package that depends on a multiarch-incompatible 
xxx-config script is broken imho.

Now an alternative to removing gpg-error-config is to make it 
compatible with multiarch. The only differences between the two copies 
are:

-libdir=${prefix}/lib/x86_64-linux-gnu
+libdir=${prefix}/lib/i386-linux-gnu
...
-           output="$output -L${prefix}/lib/x86_64-linux-gnu -lgpg-error"
+           output="$output -L${prefix}/lib/i386-linux-gnu -lgpg-error"

The -L option is not needed on Debian so it might as well be omitted.


-               host) echo "x86_64-pc-linux-gnu" ;;
+               host) echo "i686-pc-linux-gnu" ;;
...
-            echo "x86_64-pc-linux-gnu"
+            echo "i686-pc-linux-gnu"

This one is the real problem. Maybe it can be derived from some other 
source. Or maybe removing support for host would have less impact than 
removing gpg-error-config entirely.



> > libgcrypt is under consideration for use in Wine but Wine depends on
> > proper multiarch support since we need to support both 32 bit and 64 bit
> > Windows applications (even 64 bit Windows applications have 32 bit
> > installers).
> 
> What other encryption libraries has Wine considered for the purposes it
> is considering libgcrypt for?  Nettle should have comparable licensing
> concerns, a similar spread of cryptographic primitives covered, and a
> more idiomatic C interface (algortihm-specific structs, no
> S-expression string management, etc)

Wine normally uses GnuTLS. But GnuTLS is missing support for ECDH public 
key encryption. From the patch that triggered this:

https://www.winehq.org/pipermail/wine-devel/2020-January/157434.html

+/* this is necessary since GNUTLS doesn't support ECDH public key encryption, maybe we can replace this when it does:
+   https://github.com/gnutls/gnutls/blob/cdc4fc288d87f91f974aa23b6e8595a53970ce00/lib/nettle/pk.c#L495 
*/

For now this patchset is on hold to not add a new dependency to Wine.

-- 
Francois Gouget <fgouget at free.fr>              http://fgouget.free.fr/
                     f u kn rd ts, ur wy 2 gky 4 ur wn gd.