Bug#820964: [old-style-config-script-multiarch-path] false positive

[Helmut Grohne <helmut@subdivi.de>]

Control: reassign -1 libsane-bin
Control: retitle -1 libsane-bin is wrongly marked Multi-Arch: foreign

On Sat, Apr 16, 2016 at 11:37:54AM +0200, Jakub Wilk wrote:
> $ dpkg-query -Wf '${Package}\t${Architecture}\n' libsane-{dev,bin}
> libsane-bin	i386
> libsane-dev	amd64

This is precisely the setup when e.g. cross building from i386 to amd64.
The common case would be s/amd64/armhf/;s/i386/amd64/ though.

> $ sane-config --libs
> Package sane-backends was not found in the pkg-config search path.
> Perhaps you should add the directory containing `sane-backends.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'sane-backends' found

And this is how it breaks practical cross building.

The lintian check has precisely hit the right victim!

So how to fix this? Issues of this kind are non-trivial to fix properly.
I see the following options:

1) Remove M-A:foreign from libsane-bin. At this point, you can simply
   fold it into libsane-dev and remove M-A:same from libsane-dev. This
   looks super bad until you notice that in many cases libsane-dev does
   not have to be M-A:same to make cross building work. In fact, this
   will just solve most of the issues. libgpg-error-dv is in the same
   boat and we are mostly happy about that. libicu-dev is one of the
   rare cases that we need to have M-A:same (and which is currently
   marked wrongly).

2) Remove sane-config entirely. This essentially means libsane-bin would
   go away completely. Bad for downstreams relying on sane-config.

3) Remove sane-config from the interface of libsane-dev. You could
   rename libsane-bin to libsane-legacy-dev and have libsane-dev stop
   depending on libsane-bin. libsane-legacy-dev would be M-A:no and
   depend on libsane-dev. Packages that use sane via sane-config instead
   of pkg-config would then have to change their Build-Depends from
   libsane-dev to libsane-legacy-dev. Maybe find a better name for
   "legacy". A quick codesearch indicates < 10 packages affected.

I prefer 2, but think that it is infeasible here. Next up, I'd try 1
until we run into problems (if any) and switch to 3 if necessary.

Helmut