+++ 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/
Attachment:
signature.asc
Description: Digital signature