[R-pkg-team] Bug#995302: r-cran-magick: FTBFS with imagemagick 6.9.12.20

[Johannes Schauer Marin Rodrigues]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/r-pkg-team/attachments/20211001/32261c04/attachment.sig>