[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: org.apache.batik.dom.svg.SVGDOMImplementation



Hello Mathieu,
The annoying part is that even the Batik documentation still contains
the old package name:
https://xmlgraphics.apache.org/batik/using/dom-api.html

It is well possible that many of the dependencies do not use this
class. I'm not sure if there might be indirect dependencies that rely
on one of these direct dependencies to pull in Batik... they could
still use that class; although many will not build a SVG document on
their own. Loading a document from a file should not be a problem, I
believe this class is only needed to be able to manipulate the SVG
documents e.g. for animation and interaction.

According to
find -type f -name "*.jar" -print | while read l; do unzip -c "$l" |
grep -q SVGDOMImplementation && echo $l; done
the only packages I have installed that use this class are Batik, FOP and ELKI.
It may well be that the other reverse dependencies do not use this class.
Scilab for example seems to use GenericDOMImplementation, which was
not moved to a different package.

I suggest to add these for the unstable upload:
Breaks: elki (<= 0.6.5)
Breaks: libfop-java (<< 2.0)
+ add a notice to the README that the class has moved, since this is
not well documented.

I will take care of uploading a new ELKI package (probably end of the
month, or beginning of september).
It will have a version number of at least "0.7.0~20150817-1", which is
> 0.6.5, so above breaks is okay.
I assume that libfop-java 1:2.0+dfsg-1 in experimental is expecting
the new Batik version.

Regards,
Erich

On Sun, Aug 16, 2015 at 1:33 PM, Mathieu Malaterre <malat@debian.org> wrote:
> Erich,
>
> Thanks for the report about batik API compat. Could you be a little more
> verbose on what was needed to fix ELKI ? I see that that
>
> import org.apache.batik.dom.svg.SVGDOMImplementation;
>
> is still used in the ELKI (from sid).
>
> I am trying to understand if this is possible to upload 1.8 to sid with a
> debian-specific fix, then progressively upgrade dependencies to match
> upstream (removing reference to SVGDOMImplementation).
>
> Thanks much,


Reply to: