[sane-devel] [PATCH 2/2] sane-config fix, don't provide random infos

[Ruediger Meier]

On Monday 03 September 2012, Nils Philippsen wrote:
> Hi there,
>
> I should probably monitor sane-devel more closely (sue me ;-)).
>
> On Tue, 2012-02-07 at 21:24 +0100, Ruediger Meier wrote:
> > From: Ruediger Meier <ruediger.meier at ga-group.nl>
> >
> > This got broken in 26ea2a25.
> > If we configure --prefix=/tmp/bla then /tmp/bla/bin/sane-config
> > should tell us the right things instead of using any default search
> > paths. ---
> >  tools/sane-config.in |    4 ++++
> >  1 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/tools/sane-config.in b/tools/sane-config.in
> > index 1fae2e5..8e4b52a 100644
> > --- a/tools/sane-config.in
> > +++ b/tools/sane-config.in
> > @@ -10,6 +10,10 @@ scriptname="sane-config"
> >  prefix="@prefix@"
> >  exec_prefix="@exec_prefix@"
> >
> > +# using our installed *.pc only - neither default nor user paths
> > +export PKG_CONFIG_LIBDIR="@libdir@/pkgconfig"
> > +export PKG_CONFIG_PATH=""
> > +
>
> Well, this ^^ broke multilib again in 1.0.23 (but it's really my
> fault for not spotting this earlier): it makes the sane-config script
> differ between 32bit and 64bit installation, which prevents
> installing both 32bit and 64bit versions of development packages
> (which usually contain it) on the same machine, see:
>
> https://admin.fedoraproject.org/updates/FEDORA-2012-13142/sane-backen
>ds-1.0.23-1.fc17
>
> I agree that there should be a way to have sane-config produce the
> correct information if someone installs sane-backends into a private
> prefix (as long as we have it -- can we get rid of it pretty
> please?), but it should also work for both bit sizes when installed
> system-wide. I mean if someone used sane-config installed into
> /usr/bin it should work for building binaries for either ix86 or
> x86_64 if both variants are available. This was the intention of my
> original patch, i.e. defer the decision about 32bit/64bit to
> pkg-config which uses /usr/lib64/pkgconfig or /usr/lib/pkgconfig
> respectively, depending on the desired variant (i.e. default or
> whatever the user selected with setarch).

As I mentioned in one of my other emails in this thread I'd recommend to 
declare sane-config deprecated (print a warning) to let developers use 
pkg-config directly.
This is IMO much better than changing sane-config's current behavior 
just to make it usable for multiarch cases where it wasn't made for.

> BTW, now that I think about it the patch above will become faulty as
> soon as our *.pc file correctly specifies dependencies, i.e. listing
> libraries on which sane-backends depends on the "Requires:" line
> instead of hard-coding the flags in "libs". In that case, pkg-config
> won't know what flags to use since we forbade it to look in its
> default location.
>
> Any ideas how to tackle this conundrum?

You could provide patches to 3rd party projects which are currently 
using sane-config to use pkg-config instead. Note that then these 
projects will require sane-backends >= 1.0.23 if you don't keep a 
sane-config fallback.

cu,
Rudi