Hi, Quoting Andreas Tille (2021-09-30 14:09:00) > Am Wed, Sep 29, 2021 at 09:46:20PM +0200 schrieb Jeroen Ooms: > > I think the actual bug is that apt prefers > > graphicsmagick-libmagick-dev-compat over the actual libmagick++-dev. I > > don't understand why this has started happening (it wasn't the case > > for previous releases, where this problem did not happen). The > > graphicsmagick fork is quite different from imagemagick; I don't think > > they should be considered interchangeable, and certainly not > > preferred. > > As far as I was told from an endusers point of view graphicsmagick is > more stable than imagemagick. However, this does not help in this > case. However, I'm also wondering as you (Jeroen) wrote in your other > mail why graphicsmagick is involved at all. When I'm grepping my > local build-log I get: > > > Setting up imagemagick-6-common (8:6.9.11.60+dfsg-1.3) ... > Setting up libmagickcore-6-headers (8:6.9.11.60+dfsg-1.3) ... > Setting up libmagickcore-6-arch-config:amd64 (8:6.9.11.60+dfsg-1.3) ... > Setting up libmagickwand-6-headers (8:6.9.11.60+dfsg-1.3) ... > Setting up libmagick++-6-headers (8:6.9.11.60+dfsg-1.3) ... > Setting up libmagickcore-6.q16-6:amd64 (8:6.9.11.60+dfsg-1.3) ... > Setting up libmagickwand-6.q16-6:amd64 (8:6.9.11.60+dfsg-1.3) ... > Setting up libmagick++-6.q16-8:amd64 (8:6.9.11.60+dfsg-1.3) ... > Setting up libmagickcore-6.q16-6-extra:amd64 (8:6.9.11.60+dfsg-1.3) ... > Setting up libmagickcore-6.q16-dev:amd64 (8:6.9.11.60+dfsg-1.3) ... > Setting up libmagickwand-6.q16-dev:amd64 (8:6.9.11.60+dfsg-1.3) ... > Setting up libmagick++-6.q16-dev:amd64 (8:6.9.11.60+dfsg-1.3) ... > Setting up libmagick++-dev (8:6.9.11.60+dfsg-1.3) ... > > > and the build is perfectly fine.
yes, this is because apt (as Jeroen pointed out) prefers real packages over virtual ones. So the problem will *not* occur in a clean chroot environment with apt installing the build dependencies. If you think that r-cran-magick should not be built in any other way, then there is no bug and you can close this. The issue I ran into occurred because due to dependency alternatives and multiple providers of virtual packages, there exist more than one correct selection of build dependencies as far as the dependency metadata is concerned. As long as the default apt resolver doesn't change its way it picks packages, things will continue working as they do right now. But should the apt algorithm change or should the user choose a different algorithm (as I did) then the build dependencies might be satisfied by picking graphicsmagick-libmagick-dev-compat to provide libmagick++-dev. There are two ways to resolve this: either graphicsmagick-libmagick-dev-compat is wrong and it should indeed not provide libmagick++-dev because it leads to errors as in the build log I initially posted. Or, if this provides relationship is supposed to stay, all packages that do not work with graphicsmagick as a drop-in replacement for libmagick++-dev have to add a "Conflicts" relationship to indicate that property. Thanks! cheers, josch
signature.asc
Description: signature
