Hi Stephen and Bastien,
Quoting Stephen Kitt (2016-01-31 11:49:32)
> I'll give it a shot... (And add this later to the wiki.)
which page will you be editing?
> As I understand it, the page lists *dependency* problems which prevent:
It is indeed important to stress that these are only dependency problems. In
lots of places the term "build" is used, but this is simply because that term
is shorter than "test for cross build satisfiability". I just fixed this [1].
Thanks!
[1] https://gitlab.mister-muffin.de/debian-bootstrap/bootstrap_debian_net/commit/4e7326d5777516d350eb6d6cb1d18bd3785b3aa1
> * cross-building imagemagick
> * using imagemagick's packages as build-dependencies when cross-building
That is correct. In this specific example, only the "conflicts" group of
problems is shown. Other pages might also have a table for the "missing" group.
What each of these groups mean is explained right under the respective
headings. The source package-specific pages are generally just an application
of a filter to the data shown in [2] (careful, 6.6 MB of HTML) where only those
rows are shown which are either containing the source package itself or some of
the binary packages it builds. This in turn leads to the summary of its meaning
above.
[2] http://bootstrap.debian.net/cross_all.html
> The first table lists all the binary packages which prevent cross-compilation
> involving imagemagick. This tells you where you need to look if you want to
> fix things so that imagemagick can be cross-built and/or used for
> cross-compiling.
The first, small table is just a tiny version of the second. It's basically
just taking the first 10 rows and removes a bunch of columns.
> The second table lists the same information but in more detail. In each line,
> imagemagick's packages' involvement is highlighted in green. To determine
> issues preventing imagemagick from being cross-compiled, look for it in the
> third column ("packages with (possibly transitive) conflicting
> dependencies"); this shows that getting imagemagick to cross-compile involves
> fixing perl (and perl-base) so that it works in multi-arch contexts.
One of the problems shown here is, that having this information does not
automatically tell you which package is faulty or which package needs fixing.
Fixes can either be done in the depending package (by adding qualifiers like
:any or :native to dependencies) or in the depended-upon packages (by making
them multiarch:same/foreign).
Specifically, the problem here (which is a very common one) is, that
perl-base:${buildarch} needs to be installed because it is part of the
essential/build-essential set. But imagemagick also build depends on
libperl-dev and by default, this dependency will draw in
libperl-dev:${hostarch} because libperl-dev is not multiarch:foreign. Because
of this we also build depend on perl-base:${hostarch} but that one is not
installable together with perl-base:${buildarch} because perl-base is not
multiarch:same and thus the conflict. Also, note that because of the files it
contains, perl-base cannot be made multiarch:same as it is right now. Changing
this will be a big effort.
> Anything else is a situation where one of imagemagick's packages'
> dependencies prevents it being used for cross-compiling; fixing this might
> involve amending imagemagick's dependencies, or it might involve fixing the
> conflicting package. 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 hope that I got that all right and that it clarifies things a little!
Thank you!
cheers, josch
Attachment:
signature.asc
Description: signature