Hi,

having a look at src:r-cran-magick, it currently Build-Depends on
libmagick++-dev. Since graphicsmagick-libmagick-dev-compat provides
libmagick++-dev it can happen that this dependency is satisfied by the
virtual package provided by graphicsmagick-libmagick-dev-compat. This in
turn leads to a build failure reported as #995302 because
src:r-cran-magick fails to build from source if graphicsmagick is used
to compile the source instead of imagemagick. The solution that fixed
the bug was to add a Build-Conflicts with
graphicsmagick-libmagick-dev-compat as well as libgraphicsmagick1-dev.
But this made me wonder: are there other packages in the archive that
might draw in graphicsmagick via graphicsmagick-libmagick-dev-compat
instead of imagemagick and then fail to build from source?

Of the source packages that have libmagick++-dev or libmagick-dev in
their build dependency installation closure we can identify the
following groups:

1. packages that explicitly build with graphicsmagick instead of
   imagemagick

    - cimg

    The Provides is not useful here, because the source package declares
    graphicsmagick explicitly

2. packages that explicitly build with imagemagick instead of
   graphicsmagick

    - converseen
    - inkscape
    - pythonmagick
    - synfigstudio

    The Provides is not useful here, because the source package declares
    imagemagick explicitly

3. packages that FTBFS anyway and thus cannot be tested

    - digikam
    - gnunet
    - k3d
    - performous
    - pfstools
    - synfig
    - libextractor

    Irrelevant here, because we cannot compile them in unstable right
    now.

4. packages that just depend on libmagick++-dev and work with either:

    - dvdauthor
    - pstoedit
    - vdr-plugin-skinenigmang
    - zbar

    The Provides is not useful here because those packages build fine
    with the real package from src:imagemagick

5. packages that don't use either but only have libmagick++-dev or
   libmagick-dev in their closure because of libzbar-dev

    - gnome-authenticator
    - megapixels
    - nitrokey-authenticator
    - otpclient
    - pyzbar
    - gst-plugins-bad1.0

    Irrelevant, because those packages don't use imagemagick but just
    zbar.

6. packages that explicitly depend on graphicsmagick-libmagick-dev-compat

    - drawtiming
    - tango-icon-theme
    - xine-lib-1.2

    The Provides is not useful here either because those packages
    explicitly build depend on graphicsmagick-libmagick-dev-compat

7. packages that explicitly conflict with graphicsmagick

    - diffoscope
    - digikam
    - dx
    - firefox
    - gem
    - r-cran-magick

    The Provides is harmful here because packages have to explicitly
    declare a Conflicts relationship so that graphicsmagick is not
    installed instead of imagemagick.

So in summary, all uses of libmagick++-dev or libmagick-dev either do
not benefit from the Provides relationship or are actively harmed by it.

What is the rationale for the Provides. Why is it useful?

Thanks!

cheers, josch