Bug#971738: ghostscript: testing migration scripts think libz-dev:native is unsatisfiable

[Simon McVittie <smcv@debian.org>]

Source: ghostscript
Version: 9.53.3~dfsg-2
Severity: important

<https://tracker.debian.org/pkg/ghostscript> says:
* ghostscript unsatisfiable Build-Depends(-Arch) on amd64: libz-dev:native
* ghostscript unsatisfiable Build-Depends(-Arch) on arm64: libz-dev:native
* ghostscript unsatisfiable Build-Depends(-Arch) on armel: libz-dev:native
* ghostscript unsatisfiable Build-Depends(-Arch) on armhf: libz-dev:native
* ghostscript unsatisfiable Build-Depends(-Arch) on i386: libz-dev:native
* ghostscript unsatisfiable Build-Depends(-Arch) on mips64el: libz-dev:native
* ghostscript unsatisfiable Build-Depends(-Arch) on mipsel: libz-dev:native
* ghostscript unsatisfiable Build-Depends(-Arch) on ppc64el: libz-dev:native
* ghostscript unsatisfiable Build-Depends(-Arch) on s390x: libz-dev:native

For historical reasons, the real package is zlib1g-dev. libz-dev is a
virtual package that it Provides.

sbuild has no problem with a B-D on libz-dev:native and correctly installs
zlib1g-dev (at least for native builds), but the result would probably be
more predictable if the build-dependency was on zlib1g-dev:native.

>From a purely practical point of view, ghostscript is not going to migrate
to testing with this dependency, unless the testing migration scripts are
taught that virtual packages can be :native. I'll open a bug for that now,
but I think it would be wise to change this in ghostscript as well,
probably in the same upload that resolves the FTBFS #971678.

    smcv