Hi!

The current compat package pulls in c, c++, and perl dev packages of
graphicsmagick all at once. Not only are the sizes of the c/c++
packages substantial, but they carry along a train of dev package
dependencies for the corresponding image libraries. It would be
great if you can split the perl and c/c++ compat packages to reduce
the number of dependencies.

Regards,
Ramkumar.

Of course I've considered that when I first introduced the compat
package, but I was also afraid of micropackaging tiny wrapper code that
bloats the Packages file. Finally, I opted for a single blob containing
all language bindings because it's intended to be used as a temporary
band aid, eg. in Build-Depends, but not as a permanent solution.
Typically, it shouldn't be installed unless you're doing porting work or
building a depending package. So the large dependency chain should only
be a temporary nuisance. At least, that was my reasoning when taking
this choice, but of course you're very welcome to try and convince me
otherwise.

Regards,

Daniel.

Hi!

I wouldn't have been bothered too much if that was the case :) Many
packages *Depend* (not Build-Depend) on perlmagick, like
findimagedupes or html2ps for example. Now, if the user decides to
shift from ImageMagick to GraphicsMagick, he/she has to use
graphicsmagick-libmagick-dev-compat instead of perlmagick. In this
case, this package serves as an end-user requirement and not as a
developer package. It is not quite right to thrust upon such an user
so many dev packages which he/she might not at all be interested in.

Regards,
Ramkumar.

Happy 14th birthday, bug!

A lot has happened in the last 14 years, but one thing hasn't changed:
end-user tools written in Perl need something providing Image::Magick,
and if graphicsmagick-libmagick-dev-compat satisfies that then all the
development libraries for other toolchains are pulled in, unnecessarily.

One thing that has changed in the last 14 years is tooling, and the rise
of popularity of containers (docker, etc.). With that has come a renewed
focus on the footprint of images. For an image I'm working on right now,
the following are the size differences for the two providers of
Image::Magick for perl:

    libimage-magick-perl:  +29.1 MB
    graphicsmagick-libmagick-dev-compat: +94.2 MB

I respectfully submit that it still makes sense to split this package.
Current maintainers, do you agree? Would you accept patches to do this,
perhaps after Bullseye?


Best wishes,