+++ Johannes Schauer [2016-01-31 15:27 +0100]:
> Quoting Stephen Kitt (2016-01-31 11:49:32)
> > For example, hhvm can't be cross-compiled because it
> > build-depends, directly and indirectly (via imagemagick), on
> > libfreetype6-dev
> > (which contains /usr/bin/freetype-config and is therefore not multi-arch
> > co-installable).
>
> Correct. Imagemagick's build dependency on libfreetype6-dev will draw in
> libfreetype6-dev:${hostarch} while libmagickcore-dev is multiarch:foreign and
> thus will be installed for the build architecture and thus in turn
> (transitively) depends on libfreetype6-dev:${buildarch}. But
> libfreetype6-dev:${hostarch} and libfreetype6-dev:${buildarch} are not
> coinstallable because they are not multiarch:same which practically is the
> case
> because of /usr/bin/freetype-config as pointed out by Stephen. A fix could be
> to move /usr/bin/freetype-config to a separate binary package, make
> libfreetype6-dev multiarch:same (i didn't check if there are other problems
> with it) and make sure to fix all reverse dependencies which actually need
> /usr/bin/freetype-config. I don't know whether this would work or be
> practical,
> I'm just using it here as an example to show how fixing these problems can be
> very difficult.I think we need to bring this 'old-style foo-config' problem to the fore and decide what we are going to do about it. Early on in multiarch this issue was left on the 'worry about that later' pile because it didb't prevent libraries being multiarched, only -dev packages. And having -dev packages not being co-installable still allows quite a lot of cross-building, so long as you only need the host arch _or_ the build arch, not both at once. The further you get up the 'stack' the more of a problem this becomes as dependency chans grow. 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. There are presumably several hundred more which contain a foo-config script but are not listed as MA:same So this is quite a big problem. The original multiarch discussions said 'just get everyone to use pkg-config instead of internal foo-config', as then this issue doesn't arise. In many cases the pre-multiarch -config script was not arch-dependent. It said '/usr/lib/foo'. It has _become_ arch dependent because post-multiarch the lib is in '/usr/lib/<triplet>/foo. Oh the irony. 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. 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. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
signature.asc
Description: Digital signature
