Hi Wookey, On Wed, Feb 03, 2016 at 02:49:07AM +0000, Wookey wrote: > I see that there is now a lintian check for this issue whcih is great, > and gives us some idea of how big it is: > https://lintian.debian.org/tags/old-style-config-script-multiarch-path.html > > So that lists 240 packages which are MA:same and also contain an > arch-specific foo-config script.
The assumption that the tag would only hit MA:same packages is wrong. It hits e.g. libgpg-error-dev, which is correctly not marked MA:same. In defense, this tag is very young and correctly marked with with low confidence. > A second part of this problem is that foo-config scrips sometimes do > more than pkg-config does. They are used to supply other information > about the build environment. I understand that xapian is an example of > this. Another example for seeing pkg-config too limited is postgresql. #794103 > A bit of research to classify the scripts, how many packages (and > build-dependencies which use those scripts) are affected, what our > available solutions are and how many scripts are 'difficult', would be > good. I have a bit of time to apply to crossing so will try to get a > better understanding of the issue and put it on a wiki page. Another problem is packages that ship both pkg-config files and foo-config scripts. Those tend to be multiarch marked (hello icu #776821), but still contain the foo-config. Thus reverse dependencies can choose whether to use pkg-config or not and tend to get this wrong (hello libxml2). These foo-config scripts are not going away, because non-Debian users want them for backwards compatibility. What we really need is a way to keep shipping them, that doesn't break our own tools. I'm not sure that a future where we have lots of libfoo-legacy-dev packages containing just foo-config is a bright one. Helmut
