[ I am filing this bug with severity:important because bugs affecting
non-release architectures were traditionally filed with this severity
and because it makes a certain set of GNUstep packages unusable on
architectures where librsvg is not available. Please donwgrade the
severity if you don't agree. ]
gnustep-gui cannot be built on alpha, hppa, m68k and sh4 because
libmagickcore-7.q16-dev is not installable:
https://buildd.debian.org/status/package.php?p=gnustep-gui&suite=sid
This is very unfortunate, because we at the GNUstep team are switching
to a new multiarch-based layout [1] which will make some of the
packages completely unusable on these architectures if they are not
rebuilt.
src:imagemagick itself is not buildable on these architectures, and I
tried hard to understand why libmagickcore-7.q16-dev depends on
librvg2-dev. This seems completely unnecessary as AFAICS, ImageMagick
headers do not include librsvg headers and do not expose librsvg
types, linking with ImageMagick libraries does not require linking
with librsvg, and ImageMagick's pkg-config files do not require
librsvg. Perhaps I'm missing something.
It would be stupid if libgnustep-gui-dev depended on
libmagickcore-7.q16-dev just because it uses ImageMagick internally,
so I consider libmagickcore-7.q16-dev's dependency on librvg2-dev
equally stupid. Again, I may be missing something, and I don't mean
offence so please bear with me.
According to the documentation, ImageMagick uses inkscape (if
available), then resorts to librsvg and as a last resort uses an
internal implementation to handle SVG. I don't know if the latter
actually works, but I think it's better than blocking a bunch of
packages (possibly not only gnustep-gui and its rdeps).
[1] https://bugs.debian.org/1093620
P.S. We at the GNUstep team prefer to see the green colour
everywhere, and we treat all architectures equally. GNUstep is
known for its portability, and we intend to maintain that.