Unfortunately, Batik 1.8 appears to be incomatible to Batik 1.7 Therefore, upgrading the package without bumping the name will cause many applications to break.
E.g. for ELKI I had to limit Batik to the latest 1.7 version in the pom. See: http://mail-archives.apache.org/mod_mbox/xmlgraphics-batik-users/201503.mbox/%[email protected]%3E Please consider: - careful testing of packages that depend on Batik - either bouncing the package name of batik, - or setting up appropriate "Breaks" dependencies It seems that upgrading to 1.8 should not be hard, but since a class was moved to a different package, it may require touching every package that depends on Batik. I'm not a big fan of keeping around many older versions, so maybe setting versioned Breaks: for those 15-16 packages that depend on batik, and working with the affected maintainers to provide packages working with Batik 1.8 instead, is an alternative to ensure a smooth upgrade? Regards, Erich __ This is the maintainer address of Debian's Java team <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers>. Please use [email protected] for discussions and questions.
