Bug#413954: graphicsmagick-imagemagick-compat is not fully compatible to imagemagick
Control: severity -1 serious Justification: breaks reverse dependencies Hi, I am bumping this to RC because this compat package is even more broken now compared to 2007. The main reason is that ImageMagick v7 has deprecated commands like /usr/bin/convert and is moving people towards a new "magick" CLI, which this package does not provide at all. Debian has disabled this warning, but other distros are not uniformly doing so. This means that upstreams will switch over eventually, and people who have graphicsmagick-imagemagick-compat installed will be left in a broken state. Here's one example in variety, where we've made the switch because the alternative is spamming people's logs with deprecation warnings: https://github.com/varietywalls/variety/issues/728 Best, James
Bug#413954: graphicsmagick-imagemagick-compat is not fully compatible to imagemagick
Hi Bob,
On Sun, 29 Jun 2025 09:51:29 -0500 Bob Friesenhahn
wrote:
It is true that GraphicsMagick can not be 100% compatible with
ImageMagick (and makes no effort to follow ImageMagick changes), except
for the precise version it branched from. It is also true that
ImageMagick is not compatible with prior ImageMagick versions and
continues to change its interfaces and behavior rapidly.
Debian has been distributing ImageMagick 6, which is a sort of LTS
version of ImageMagick, but ImageMagick 7 differs from ImageMagick 6 in
many ways, and in fact it has deprecated the 'convert' command and
prefers to be invoked as 'magick' ("WARNING: The convert command is
deprecated in IMv7, use "magick" instead of "convert" or "magick convert"").
Debian ships ImageMagick v7 in testing/unstable and this is probably
what will make the next release (trixie). However it seems the "convert"
command deprecation was patched out for now[1].
It looks like the GraphicsMagick docs use "gm convert" etc. in the
examples instead of bare commands like "convert". If both GraphicsMagick
and ImageMagick are moving towards different commands, we should stop
having one provide another. Perhaps a better solution would be having
both declare Provides: against some common package names like "convert",
"mogrify", instead?
Do any of the package maintainers have any thoughts on this?
[1]:
https://sources.debian.org/patches/imagemagick/8:7.1.1.47%2Bdfsg1-1/0029-Remove-deprecation-warning.patch/
It appears that ImageMagick6 changed its syntax from '-map netscape:' to
'-remap netscape:', and eliminated '-map' entirely.
Bob (GraphicsMagick Maintainer)
Best,
James
On 6/28/25 14:03, James Lu wrote:
> Hi maintainer,
>
> *Please* consider getting rid of this Provides. It's been causing
> sporadic build failures for 18 years! graphicsmagick forked from
> imagemagick over 20 years ago and it's clear that they've diverged far
> too much for graphicsmagick to be a drop-in replacement. (This
> shouldn't even be a surprise, considering the time frame.)
>
> Anyways, this Provides is causing icoextract builds in experimental to
> fail[1]. I am not sure why this package got picked as a build-dep by
> the buildd to begin with, but even when I remove a bunch of
> unsupported convert flags, I am blocked because graphicsmagick does
> not support creating .ICO files while imagemagick does[2]:
>
> $ make testapp.ico
> convert testapp.png -resize 16x16 tmp-testapp-16.bmp
> convert testapp.png -resize 32x32 tmp-testapp-32.bmp
> convert testapp.png -resize 48x48 tmp-testapp-48.bmp
> convert testapp.png tmp-testapp*.bmp testapp.ico
> convert: No encode delegate for this image format (ICO).
> make: *** [Makefile:15: testapp.ico] Error 1
> root@86890e20afd5:/tmp/src/tests# convert testapp.png testapp.ico
> convert: No encode delegate for this image format (ICO).
>
> Policy 7.5 suggests I can work around this with a versioned
> dependency[3] on imagemagick, but I don't think I should need one to
> begin with. When I build-dep on something I expect to get that, or
> something that's actually compatible :/
>
> [1]:
> https://buildd.debian.org/status/fetch.php?pkg=icoextract&arch=all&ver=0.2.0-1&stamp=1750623272&raw=0
> [2]: https://sourceforge.net/p/graphicsmagick/feature-requests/71/
> [3]:
> https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides
>
> Best,
> James
>
Bug#413954: graphicsmagick-imagemagick-compat is not fully compatible to imagemagick
It is true that GraphicsMagick can not be 100% compatible with
ImageMagick (and makes no effort to follow ImageMagick changes), except
for the precise version it branched from. It is also true that
ImageMagick is not compatible with prior ImageMagick versions and
continues to change its interfaces and behavior rapidly.
Debian has been distributing ImageMagick 6, which is a sort of LTS
version of ImageMagick, but ImageMagick 7 differs from ImageMagick 6 in
many ways, and in fact it has deprecated the 'convert' command and
prefers to be invoked as 'magick' ("WARNING: The convert command is
deprecated in IMv7, use "magick" instead of "convert" or "magick convert"").
It appears that ImageMagick6 changed its syntax from '-map netscape:' to
'-remap netscape:', and eliminated '-map' entirely.
Bob (GraphicsMagick Maintainer)
On 6/28/25 14:03, James Lu wrote:
Hi maintainer,
*Please* consider getting rid of this Provides. It's been causing
sporadic build failures for 18 years! graphicsmagick forked from
imagemagick over 20 years ago and it's clear that they've diverged far
too much for graphicsmagick to be a drop-in replacement. (This
shouldn't even be a surprise, considering the time frame.)
Anyways, this Provides is causing icoextract builds in experimental to
fail[1]. I am not sure why this package got picked as a build-dep by
the buildd to begin with, but even when I remove a bunch of
unsupported convert flags, I am blocked because graphicsmagick does
not support creating .ICO files while imagemagick does[2]:
$ make testapp.ico
convert testapp.png -resize 16x16 tmp-testapp-16.bmp
convert testapp.png -resize 32x32 tmp-testapp-32.bmp
convert testapp.png -resize 48x48 tmp-testapp-48.bmp
convert testapp.png tmp-testapp*.bmp testapp.ico
convert: No encode delegate for this image format (ICO).
make: *** [Makefile:15: testapp.ico] Error 1
root@86890e20afd5:/tmp/src/tests# convert testapp.png testapp.ico
convert: No encode delegate for this image format (ICO).
Policy 7.5 suggests I can work around this with a versioned
dependency[3] on imagemagick, but I don't think I should need one to
begin with. When I build-dep on something I expect to get that, or
something that's actually compatible :/
[1]:
https://buildd.debian.org/status/fetch.php?pkg=icoextract&arch=all&ver=0.2.0-1&stamp=1750623272&raw=0
[2]: https://sourceforge.net/p/graphicsmagick/feature-requests/71/
[3]:
https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides
Best,
James
Bug#413954: graphicsmagick-imagemagick-compat is not fully compatible to imagemagick
Hi maintainer, *Please* consider getting rid of this Provides. It's been causing sporadic build failures for 18 years! graphicsmagick forked from imagemagick over 20 years ago and it's clear that they've diverged far too much for graphicsmagick to be a drop-in replacement. (This shouldn't even be a surprise, considering the time frame.) Anyways, this Provides is causing icoextract builds in experimental to fail[1]. I am not sure why this package got picked as a build-dep by the buildd to begin with, but even when I remove a bunch of unsupported convert flags, I am blocked because graphicsmagick does not support creating .ICO files while imagemagick does[2]: $ make testapp.ico convert testapp.png -resize 16x16 tmp-testapp-16.bmp convert testapp.png -resize 32x32 tmp-testapp-32.bmp convert testapp.png -resize 48x48 tmp-testapp-48.bmp convert testapp.png tmp-testapp*.bmp testapp.ico convert: No encode delegate for this image format (ICO). make: *** [Makefile:15: testapp.ico] Error 1 root@86890e20afd5:/tmp/src/tests# convert testapp.png testapp.ico convert: No encode delegate for this image format (ICO). Policy 7.5 suggests I can work around this with a versioned dependency[3] on imagemagick, but I don't think I should need one to begin with. When I build-dep on something I expect to get that, or something that's actually compatible :/ [1]: https://buildd.debian.org/status/fetch.php?pkg=icoextract&arch=all&ver=0.2.0-1&stamp=1750623272&raw=0 [2]: https://sourceforge.net/p/graphicsmagick/feature-requests/71/ [3]: https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides Best, James
