On 2015-05-27 08:09, tony mancill wrote: > On Tue, 26 May 2015 17:54:17 +0200 Niels Thykier <ni...@thykier.net> wrote: >> On 2015-05-26 17:25, Thorsten Glaser wrote: >>> On Tue, 26 May 2015, Niels Thykier wrote: >>> >>>> I agree that the is a good idea to clarify this. My personal >>>> recommendation is to declare that: >>>> >>>> * gcj-jdk is not considered a suitable Java implementation for our end >>>> users nor for implementing the default-java. >>> >>> Please do not do that. Way too much software, even *really* deep >>> down in the cycle, things like gettext, depend on default-jdk and >>> build java versions of their libraries. Even if they donât work >>> as well as the OpenJDK versions, or donât work at all, they still >>> prevent the source packages FTBFSing and provide Build-Depends for >>> lots of other packages. >>> >> >> While a valid concern, I personally disagree that this is sufficient >> reason to keep the "silently broken" behaviour, which is our status quo. >> That said, as I am not going to implement the change, I am not the one >> you need to convince. >> >>> If you really want to go this route, please ensure that Debian can >>> still work on OpenJDK-less architectures first, by removing the >>> java packages from all those source packages. >>> >>> Thanks. >>> >>> bye, >>> //mirabilos >>> >> >> This is certainly a possible solution. Another would be to make them >> build-depend on gcj-jdk, if they are truly java5 compatible. I believe >> gettext is mostly in the latter category - my guess is that they have >> not touched those bindings considerably in many years. >> >> My concern with gcj-jdk implementing default-java is that it leads to >> silent breakage because gcj-jdk is stuck in ("almost") Java5 support >> while Debian is moving to OpenJDK-8 with lambda functions, tons of new >> classes etc. This breakage is /not/ discovered by us, but by our end >> users that consumes ports without OpenJDK support and I think that is >> the wrong signal to send to our users. > > This is primarily a +1 regarding the points that Niels has made... > > Requiring gcj-jdk/Java5 compatibility in any broad sense ignores the > evolution and current state of the language and applications as they are > used by the large majority of our users. (It also turns the "busy" knob > up to 11.) > > So it seems like life would be easier if default-jdk were equivalent to > openjdk-7. This still covers a large number of architectures [1], and > comparing these to the ports supported by default-jdk [2], the only > architectures left out are: hppa, hurd-i386, and m68k. (I believe that > sparc *is* sparc64, if I'm not mistaken.)
I suspect mips and mipsel are soon to be added to the "left out" architectures. Also, sparc is sparc 32bit userspace, there is sparc64 port in Debian. > For those packages that are > deep in the dependency graph and are still java5-compatible, it seems > like it would be sufficient to build depend on default-jdk | gcj-jdk. > ... and the sufficient logic to find the correct JAVA_HOME. > However, couldn't we use versioned build-deps on default-jdk + the > virtual runtime dependency for the binary package to accomplish the same > effect? For any software that requires Java7, we would build-dep on > default-jdk (>=2:1.7~) and require java7-runtime for the resulting > binary package. (The versioned build-dep has already been used in some > cases to excluce gcj-jdks.) > STOP! Versioned dependencies on default-java for pulling a particular Java version IS A BAD IDEA! We have twice now added an epoch to default-jdk et al, because we had to revert the default java on several architectures. So far it has always been openjdk -> gcj, but it could just as well be openjdk-8 to openjdk-7 next time. As soon as the epoch is bumped, you get the old java version while the dependency is still satisfied! To be honest, I mostly of the belief that using the java major version as a part of the version for default-jdk et al. is a misfeature. It appears to trick people into believing it is useful method to ensure a minimum java version, only to be surprised by an "oops, we have to revert to gcj and have to bump the epoch". > For Java8, the pattern would be the same, and it won't be long before > we'll have to accommodate sources that *require* Java8. The versioned > dependency would allow us to differentiate between source packages that > require 8 (or 9) and those that will still build with Java 7, etc. > No, I am not convinced it will (as per above). Perhaps we should have a look at versioned provides as an alternative. > [...] > > Thanks for the discussion, > tony > > [1] https://packages.debian.org/unstable/openjdk-7-jdk > [2] https://packages.debian.org/unstable/default-jdk > > Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org