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 <fgou...@free.fr> http://fgouget.free.fr/
f u kn rd ts, ur wy 2 gky 4 ur wn gd.
