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
signature.asc
Description: signature
