pkg-config and backports

[Ferenc Wágner]

Etienne Dysli-Metref <etienne.dysli-metref at switch.ch> writes:

> I'm trying to backport Shibboleth packages to Wheezy, starting with
> xml-security-c and ran into the issue that Wheezy has an older version
> of pkg-config that does not support PKG_INSTALLDIR. Since you wrote
> earlier (in thread "log4shib and pkg-config"):
>
>> PKG_INSTALLDIR can be yanked out with no loss of previous functionality,
>> as it wasn't configurable at all.
>
> I tried to remove it from the patch
> 'debian/patches/Use-pkg-config-for-Xerces-OpenSSL-and-NSS-and-provid.patch'.
> I also had to add a definition of 'pkgconfigdir' for the build to work,
> but I'm not sure about the right value/place to put it. Here are my
> modifications:
>
> diff --git
> a/debian/patches/Use-pkg-config-for-Xerces-OpenSSL-and-NSS-and-provid.patch
> b/debian/patches/Use-pkg-config-for-Xerces-OpenSSL-and-NSS-and-provid.patch
> index a84f573..fdc2dc8 100644
> ---
> a/debian/patches/Use-pkg-config-for-Xerces-OpenSSL-and-NSS-and-provid.patch
> +++
> b/debian/patches/Use-pkg-config-for-Xerces-OpenSSL-and-NSS-and-provid.patch
> @@ -17,10 +17,11 @@ diff --git a/Makefile.am b/Makefile.am
>  index 4a65b87..3737973 100644
>  --- a/Makefile.am
>  +++ b/Makefile.am
> -@@ -19,6 +19,8 @@ ACLOCAL_AMFLAGS = -I m4
> +@@ -19,6 +19,9 @@ ACLOCAL_AMFLAGS = -I m4
>
>   SUBDIRS = xsec
>
> ++pkgconfigdir = $(libdir)/pkgconfig
>  +pkgconfig_DATA = xml-security-c.pc
>  +
>   EXTRA_DIST = \
> @@ -30,14 +31,6 @@ diff --git a/configure.ac b/configure.ac
>  index 8591297..1457fe1 100644
>  --- a/configure.ac
>  +++ b/configure.ac
> -@@ -23,6 +23,7 @@ AC_CONFIG_AUX_DIR(build-aux)
> - AC_CONFIG_MACRO_DIR(m4)
> - AM_INIT_AUTOMAKE([subdir-objects])
> - AC_PROG_LIBTOOL
> -+PKG_INSTALLDIR
> -
> - AC_ARG_ENABLE(debug,
> -     AS_HELP_STRING([--enable-debug],[Have GCC compile with symbols
> (Default = no)]),
>  @@ -39,7 +40,7 @@ fi
>
>   # Define the files we wish to generate
>
> Does this sound reasonable/correct to you?

Absolutely.  Also, I think putting a new patch on top of the current
queue would be simpler and easier to manage than changing the patch file
itself.  But that's a question of taste, both lead to the same result.
-- 
Regards,
Feri