* Helmut Grohne <helmut@subdivi.de>, 2016-05-09, 06:47:
The first misconception I see in this thread is that somehow pkg-config is
good and foo-config is bad. It's not as simple as that. Have a look at
libpython3-dev. It ships e.g. x86_64-linux-gnu-python3-config.
This is an unfortunate example, because Python upstream supports pkg-config,
unlike arch-qualified python*-config. (Why do we need the latter then? Go figure.)
So when converting your foo-config scripts to use pkg-config, you can go ahead
and parse $0. Use that triplet instead of encoding it into your script. Then
each libfoo-dev instance can place the same (shared) foo-config script in a
shared location and place individual symbolic links with the prefix at it.
But then to actually take advantage of the newfangled <triplet>-foo-config,
you'll have to patch foo-config users. So why not patch them to use
<triplet>-pkg-config directly?
Here are my foo-config vs Multi-Arch tips:
* Don't read descriptions of old-style-config-script* Lintian tags. They are awful.
* It's often possible to make the script architecture-independent with little
work. See #796770 for example.
* If the above doesn't work (or even if it does!), try persuading upstream to
ship pkg-config files. And maybe ask them to deprecate foo-config. This might
let you drop the foo-config in the (very far) future.
If none of this works, it's probably not the end of the world if your -dev
package is not MA:same. Creating <triplet>-foo-config, especially when it's not
going to be adopted upstream, is most likely counter-productive.