Package: graphicsmagick-libmagick-dev-compat
Severity: normal
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
