Le 16/07/2014 11:24, Rene Engelhard a écrit : > Bad, but other packages broken is not a reason to break more. > > *any* Java application which is built on/for kfreebsd-* (which has native > stuff) or _all (where it's available on kfreebsd-*, too)
I understand that would be ideal but that's unrealistic. Java 5 is ten years old, upstreams are increasingly dropping support for Java 5 and 6, we can't fight that. Tomcat 7 requires Java 6, Tomcat 8 requires Java 7, and there is more with every update. > You man Conflicts: gcj, gcj-jdk? :) Defining a conflict would be a bit strong. I was rather thinking about a wiki page listing the essential Java packages that must remain compatible with gcj (like Ant, LibreOffice and their dependencies). We could then schedule a periodic rebuild of these packages with gcj to ensure we are not regressing. > The problem is not (only) compilation, but also runtime. Lo for example > has stuff disabled on gcj-builds because it does not work and some > Java commons libs now need 1.6 to build and run etc... If these disabled features are important we could fork the libs into separate packages compatible with gcj (something like libcommons-foo-java5backport-java). Thus we could more forward and preserve the gcj compatibility where it matters. > Anyway, I *do* see your point but not *now*, so short before the freeze. > A loads of packages probably need changes to disable Java, get binary packages > removed, etc. Ok let's shelve my suggestion for now. Thank you for your input Rene. Emmanuel Bourg -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c64b3f.2050...@apache.org
