Jan Schulz wrote:
It seems that some packages use xalan directly and having it upgrading
I've not looked at fop but as I've said, the currently packaged libxalan2-java includes additional external classes in xalan2.jar and FOP might use them to access the XSL transformer.
to a newer breaking API version will break this apps. Therfore I think it would make some sense to treat this packages 'as API' as long as wehave software, which uses internal API.
The API will stay comaptible. As I've said, the new Xalan version is compatible with what is currently packaged as libxalan-java. It's the same as with libc6 - the public API gets extended but stays compatible.
I have no idea, how fop uses xalan, but if it is like 'call the app', then libxalan-java should probably become 'xalan' anyway.
I've already thought about this. But unfortunately the source package that builds libxalan16 (the C implementation of Xalan) is already called xalan. :-(
Another 'IMO': Everything with lib in front should be 'library packaged'. Otherwise it wouldn't be 'lib' (I know that this isn't true with some normal packages, but... :)
I disagree. For example, libtomcat4 is not - and should not be - packaged as a "traditional Java library". It would not make much sense to put all the JARs in /usr/share/java. The same is true for libant1.6-java with its separated JARs.
Stefan