Hi, On Wed, 2005-05-04 at 19:22 -0400, David Walluck wrote: > Then, our first problem comes from eclipse-ecj. If this is supposed to > come from eclipse, then there is a major bootstrapping problem, as > eclipse has many dependencies. However, ecj used to be distributed > separately. I tried building it, but it relies on katana, and the build > for ecj fails when katana fails with some exception. Anyway, I don't > know if the current wrapper scripts for gcj-compat even honor this > eclipse-ecj jar which has a different name than the current eclipse-ecj > as far as I can tell. > Yes, we know about this circular dependency. We didn't want to create and maintain an eclipse-ecj RPM separate from the Eclipse package. The real solution here is to make gcj -C a true replacement for javac. gcjx will make this happen, hopefully in time for Fedora Core 5. In the meantime it would be very useful to create a pure bytecode eclipse-ecj package, buildable by gcj -C, for distribution by jpackage.org. I wanted to do this when I first submitted java-gcj- compat to JPackage but I never got around to it. All the logic will be in the Rawhide Eclipse spec file, since we bootstrap ecj using gcj -C. > Note that ecj is still in fedora development, but katana is not (even > though it is required by eclipse-ecj). > > A minor issue seems to be that classpathx-mail requires > classpath-inetlib-javadoc, only I can't find a separate > classpath-inetlib package. Instead, it seems to be in the > classpathx-mail rpm, in which case no package can provide the > classpath-inetlib-javadoc dependency that is needed. > > The other major problem is jessie. Does java-1.4.2-gcj4.0-compat really > need jessie? Probably it does not for any of the base requirements. It > may be possible to leave this requirement out initially, or leave it out > together, and pull in jessie some other way. > I'm working on a patch that will merge Jessie into GNU Classpath/libgcj which will eliminate this dependency. Tom