On Tue, 26 May 2015 17:54:17 +0200 Niels Thykier <niels@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
Attachment:
signature.asc
Description: OpenPGP digital signature