Hi James
I don't think removing the compat packages should break anything, since
the packages they are providing already exist separately. What exactly
is failing to build?
There are plenty of packages that build-depend on
graphicsmagick-imagemagick-compat explicitly - many were advised to do
so for the reasons that graphicsmagick exists in the first place - to
use tools with a stable interface. Those packages now FTBFS because
graphicsmagick-imagemagick-compat has no installation candidate.
(I)Doseparse: Parsing and normalizing...
(I)Dose_deb: Parsing Packages file -...
(I)Dose_common: total packages 73333
(I)Dose_applications: Cudf Universe: 73333 packages
(I)Dose_applications: --checkonly specified, consider all packages as
background packages
(I)Dose_applications: Solving...
output-version: 1.2
native-architecture: amd64
report:
-
package: sbuild-build-depends-main-dummy
version: 0.invalid.0
architecture: amd64
status: broken
reasons:
-
missing:
pkg:
package: sbuild-build-depends-main-dummy
version: 0.invalid.0
architecture: amd64
unsat-dependency: graphicsmagick-imagemagick-compat:amd64
build-rdeps is needed here but of course that will include alternative
build-deps (but only the first alternative is used on the sid buildds),
and it might also include packages that b-d on imagemagick because of
the Provides of graphicsmagick-imagemagick-compat.
How many explicitly b-d on graphicsmagick-imagemagick-compat vs how many
are there via the Provides I don't know. That's all stuff to do before
removing the binary package.
Stuart
--
Stuart Prescott http://www.nanonanonano.net/ [email protected]
Debian Developer http://www.debian.org/ [email protected]
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
