Re: openjdk maintenance for wheezy and squeeze
Niels Thykier <niels@thykier.net> schrieb:
> On 2013-02-17 23:04, Matthias Klose wrote:
>> There is a bug report open for openjdk-6 in wheezy (#675495) and squeeze didn't
>> see any security updates for several months. To summarize, no party involved is
>> capable or willing to provide security updates based on backports of single
>> patches to the released openjdk-6 version in a stable release. So what to do
>> about it?
>>
>
> Hi,
>
> Thanks for bringing up this topic. Here is my view on it:
>
>> - Remove openjdk-6 in wheezy. Probably would require falling back to
>> gcj. Not recommended as a runtime environment, but should work fine
>> for building packages, as ecj is used for byte-code compilation.
>> Falling back to an easier-to-main jvm could be an option too, but
>> I didn't check how well that would work.
>> Not having a fall-back would require removing most of java in Debian.
>>
>
> I do not believe this is a functional solution. In my experience, gcj
> is not capable of running a lot of our Java programs reliably.
>
>> - Updating to openjdk-7 in wheezy would not solve any issues from my
>> point of view, and it would need some porting of packages to 7, and
>> probably removing some packages which are not yet ported.
>> Otoh removing openjdk-7 for wheezy could be an option if only one
>> version should be supported for a stable release.
>>
>
> We tried to accomplish this (replacing openjdk-6 with openjdk-7) a
> couple of months before the freeze; there was too much then and the
> freeze has not changed that. If we were to do this, we should have done
> it before the freeze (and continued in the early freeze).
>
>> - Release openjdk-6 with wheezy, and provide security support by
>> updating to new OpenJDK and IcedTea versions. Usually this does
>> include some backports and other fixes. The potential for
>> regressions could be higher, however even the single security fixes
>> show regressions, as shown by the last security update on Feb 1.
>>
>> These builds could be provided as security updates, updates to
>> the stable releases, or as backports. As a proof of concept, see [1].
>>
>
> I am sad to hear that stable releases are having regressions (especially
> for security fixes), but I do not see a way to release Wheezy without
> OpenJDK-6 (as default java).
>
>> - Release openjdk-7 with wheezy, and do the same as with openjdk-6.
>> The issue here is that 7 sees more changes than 6, and that the
>> current openjdk-7 release doesn't build anymore on mips or mipsel,
>> as communicated to the Debian mips porters, so an update would
>> require removal of the binary mips packages. Fine if somebody wants
>> to fix it, but apparently there is no-one interested in that. So
>> this looks more difficult than the openjdk-6 updates. Removing
>> the openjdk mips binaries would require changes to source packages
>> building arch any packages and build-depending on default-jdk or
>> openjdk.
>>
>
> openjdk-7/7u3-2.1.3-1 is currently in testing, so we would release
> openjdk-7 with Wheezy? Admittedly with the security bugs in Java
> currently, I suspect the u13 might be better for us.
> That said, I got the feeling that this option would include us
> replacing the default-jdk with openjdk-7? As mentioned above, I don't
> see how that can happen with breaking a lot (unless we only change the
> default plugin).
I've looked into the openjdk/icedtea in disguise situation of the last days.
It's great to see that their will be ongoing icedtea6 releases. I wasn't
aware of that so far.
Backporting security fixes with Java has turned out to be more of less
unfeasible. I tried this once with DSA 2507 and I think that amounted to at least
two man days of work for that update alone. Also, Ubuntu has shipped
backports to all suites in USN-1724 and AFAICS the world hasn't stopped.
After all, everyone using Oracle Java will be exposed to the same
behaviourial changes.
So we should proceed with providing backports for openjdk in the future.
If Matthias keeps the Debian/Ubuntu packaging in a state that it's easily
buildable on squeeze/wheezy for ojdk6 and for wheezy on ojdk7 I think
we should be able to handle Java updates resource-wise.
I'm not familiar with the Java internals, but if we're following that approach
it would make sense to upgrade Wheezy to the version in experimental
(i.e. 7u15 instead of 7u3).
Cheers,
Moritz
>
>
>
> I recognise that OpenJDK-7 would most likely have been better default.
> However, I do not think it is possible for us to change the default-java
> at this point of the freeze without great distruption.
>
> * Even if we were to change the default to OpenJDK-7, we would still
> have a lot way to go before we could get rid of OpenJDK-6.
>
> * Using GCJ as default java will just cause programs to fail/crash. I
> believe I mentioned this to you at UDS-R; I do not think GCJ should
> be a provider of Java for programs anymore (for fixing post Wheezy).
> To my knowledge it is (at best) a Java5 claiming to support both
> Java6 and Java7 - and when called on that bluff the program has to
> terminate (usually for missing methods or classes in the "std"
> library).
>
>> We should find a solution where the resources are available to handle this
>> solution. In the OpenJDK team, I think it's safe to assume that Torsten Werner
>> isn't currently working on openjdk anymore and recently I got an email from
>> Damien Raude-Morvan, that he can't work on OpenJDK-7 in the forseeable future
>> anymore. Apparently one of the security team members who did work on OpenJDK
>> security updates left the team too. I think that moving maintainership to the
>> Debian Java team would just make the maintainership issue less explicit.
>>
>
> I agree it would be nice to have more hands on packages like OpenJDK;
> but I suspect OpenJDK is sufficiently intimidating to scare people away
> at first (or even second) sight. I know from experience with Eclipse
> that people offered help, but in practise never submitted any patches
> (or at best did one or two trival things and then we never heard from
> them again on Eclipse).
> I would love to say that I could jump in there and help you out; but I
> expect I won't be of much help to you and would eventually just become
> "that guy in the uploader's list that never does anything".
>
>> While not a that important issue, the mips and kfreebsd issue could be improved
>> as well:
>>
>> - The mipsel porter box is again down for several months. Having a porter
>> box to test backports would be appreciated (yes, openjdk-7 in experimental
>> currently fails on mips, not mipsel).
>>
>
> I believe you and I talked about dropping mips from the Java7 list if no
> one stepped up to assist here (at UDS-R)? I could see that happen in
> Jessie - actually for Java7, I suppose it could happen in Wheezy as well
> since OpenJDK-6 will stay (for better and for worse).
>
>> - Afaik openjdk-7 for kfreebsd does build on kfreebsd (according to Damien)
>> with the kfreebsd kernel from wheezy. So maybe some commitment could be
>> found to upgrade and maintain the kernels before wheezy is released?
>>
>
> While OpenJDK-7 on kfreebsd would be great, I do not think it will help
> us for Wheezy. Sure for Jessie it would mean a proper Java
> implementation on kfreebsd and would be (IMHO) an important step in
> removing GCJ from the alternatives list.
>
>> Matthias
>>
>> [1] deb http://people.debian.org/~doko/tmp/openjdk-6-squeeze ./
>>
>>
>
> TL;DR: Yes, it sucks, but I don't see how we can change/improve the
> situation without setting the freeze back at least 3 months if not more.
>
> ~Niels
>
>
>
Reply to: