[pkg-gnupg-maint] Bug#643341: Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful

[NIIBE Yutaka]

Hello,

Thanks for your explanation.  I learn.

Let me explain from GnuPG development side.  We care traditional UNIXen
and unusual OSes.  (minimum version of) GnuPG should be able to be built
and installed in early stage of development.

Simon McVittie <smcv at debian.org> wrote:
> Control: tags -1 - wontfix

OK.

> That will fix cross-compilation if dependent packages are changed to
> use (for example) PKG_CHECK_MODULES([GPG_ERROR], [gpg-error >= 1.33])
> instead of AM_PATH_GPG_ERROR([1.33]).

Yup.  That is my intention.

But... please note that, we don't have an idea doing like that for GnuPG
and its friends.  For building GnuPG, pkg-config (or its alternatives)
should not be one of requirements.

> Is https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=blob;f=src/gpg-error-config-new.in
> the new script?

Yes.

> It's very unusual to parse .pc files "by hand" like this.

I know.  Someone has to do unusual thing to break a tie.  I don't think
it's a good solution, but it makes sense in this situation.  Ugly
compromise, but I did my best to provide gpg-error.pc from upstream.

> The usual way to consume .pc files is to run pkg-config (the reference
> implementation in C) or pkgconf (a reimplementation in Perl).

Perhaps, you mean PkgConfig.  It seems it lacks PKG_CONFIG_SYSROOT_DIR
support.

There is another alternative, pkgconf in FreeBSD.  This looks easier
to build.

> For Debian, I wonder whether we might be able to patch the script to
> remove this part, which looks like the only architecture variation:
>
>     prefix=@prefix@
>     exec_prefix=@exec_prefix@
>     libdir=${PKG_CONFIG_LIBDIR:- at libdir@}
>     PKG_CONFIG_PATH="$PKG_CONFIG_PATH${PKG_CONFIG_PATH:+:}${libdir}/pkgconfig"

For Debian, where we can assume good environment, package maintainer(s)
can do many things.  I'd suggest something like:

   (1) Having architecture independent -dev package _and_
       architecture dependent -dev package,

   (2) by installing original gpg-error-config as
       <triplet>-gpg-error-config,

   (3) ... and installing Debian specific gpg-error-config
       which detects architecture dependent path dynamically.

Just an idea.  I don't know this feasibility.

> This is not usually possible. If I run gpg-error-config, for example like
> this:
>
>     https://sources.debian.org/src/deja-dup/38.0-1/meson.build/?hl=60#L60
>
> how do you know which architecture I wanted?

Should libdir have the triplet in multiarch environment?
Or simply invoking 'dpkg-architecture -qDEB_HOST_GNU_TYPE'?


			*	*	*

These posts from me are basically to inform forthcoming upstream
changes.  I don't insist changes for Debian packaging.  It's up to
Debian.

On the other hand, we are welcom to improve libgpg-error to be Debian
friendly (but not Debian specific).
--