reassign 537290 classpath-common
thanks
No, there's nothing wrong with gcj-jdk. It defines a conflict with the current
classpath-common. What needs to be done: update classpath to 0.98, build cacao
using the new classpath, then decide what to do with the tools which are both
built by gcj-jdk and classpath, if we want to avoid the conflict.
classpath/cacao should at least provide something like /usr/lib/jvm/<something>
and provide alternatives as other JVM's do.
Maybe it is a help to provide a new cacao-source source package just building
the cacao-source binary package, which then is then used by classpath and
openjdk-6 to build the cacao runtime.
If nobody is interested in classpath, then we maybe should remove it.
Matthias
On 16.07.2009 14:10, Daniel Schepler wrote:
Package: classpath-common, gcj-jdk
Severity: serious
classpath-common and gcj-jdk both have the file
/usr/share/man/man1/gappletviewer.1.gz. It seems gcj-jdk tried to "fix" the
issue using a versioned conflict with classpath-common; however, that makes
cacao's Build-Depends unsatisfiable as it Build-Depends on both classpath-
common and default-jdk-builddep (at least on !alpha).
Wouldn't it make sense to handle this as an alternative, since gcj uses
classpath libraries anyway?
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
