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/%3c55157c80.4030...@ptc.com%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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
