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.) 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. 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.) 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. I realize that this requires us to touch a large number of packages (basically, those that won't build with the unversioned default-jdk), and Niels' proposal is certainly less work in the short-term. But I suspect we may have to start touching those packages and worrying about the version of default-jdk to handle Java7/8/9 anyway... Thanks for the discussion, tony [1] https://packages.debian.org/unstable/openjdk-7-jdk [2] https://packages.debian.org/unstable/default-jdk
signature.asc
Description: OpenPGP digital signature