[Pkg-gmagick-im-team] Bug#413954: graphicsmagick-imagemagick-compat is not fully compatible to imagemagick

[James Lu]

Hi Bob,

On Sun, 29 Jun 2025 09:51:29 -0500 Bob Friesenhahn 
<bobjfriesenhahn at gmail.com> 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 at 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
> >
> 
>