F22 System Wide Change: Legacy implementations of the Java platform in Fedora

Mikolaj Izdebski mizdebsk at redhat.com
Tue Feb 24 15:12:20 UTC 2015

On 02/24/2015 04:06 PM, Deepak Bhole wrote:
> * Mikolaj Izdebski <mizdebsk at redhat.com> [2015-02-24 09:58]:
>> On 02/24/2015 03:32 PM, Deepak Bhole wrote:
>>> * Dominik 'Rathann' Mierzejewski <dominik at greysector.net> [2015-02-24 09:29]:
>>>> On Tuesday, 24 February 2015 at 15:09, Deepak Bhole wrote:
>>>>> * Dominik 'Rathann' Mierzejewski <dominik at greysector.net> [2015-02-24 09:04]:
>>>>>> On Tuesday, 24 February 2015 at 14:28, Jiri Vanek wrote:
>>>>>> [...]
>>>>>>> There were several attempts in past like "can you please support jdk
>>>>>>> 7,6...in newer fedoras" and we always told no. When come speech about "do it
>>>>>>> on your own" suddenly many questions marks raised up.
>>>>>>> The last open bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1190137
>>>>>>> the guy is willing to maintain it.
>>>>>> Fine, so let him do it and drop the Obsoletes: tag in java-1.8.0-openjdk
>>>>>> and its successors. You shouldn't arbitrarily block people from
>>>>>> re-introducing an older branch of any package back into Fedora in the
>>>>>> first place.
>>>>> We have no intention of blocking it. The reason for proposing these
>>>>> restrictions is that the Fedora Java stack will not work with older
>>>>> JDKs, therefore we need to make sure that it goes not get installed on
>>>>> the system unless explicitly requested by someone who knows what they
>>>>> are doing.
>>>> Well, you do that by adding/updating (Build)Requires: in the packages
>>>> which won't work otherwise, not by adding Obsoletes:.
>>> That would generally work for most packages, but there is a new JDK
>>> released every 2 years. This means that we would have to change the BR
>>> and Requires for the entire Java stack (100s and 100s of packages) every
>>> 2 years, which is non-trivial.
>> First, we have versioned auto-requires generated during package build.
>> Explicit requires on java aren't usually needed. If package requires
>> "java > 1:1.7" then it is correct - the package can be assumed to work
>> with older JDK.
> While that is true in terms of source compatibility, it will work only
> if it is compiled with the older JDK.
>> Secondly, it is fairly easy to add requires on "java-devel >= 1:1.8" to
>> packages related to build systems like ant, maven or gradle. This would
>> cover most cases of building Java packages using latest JDK.
> As you stated, it will cover most cases, but not all. More critically,
> this does not solve the issue with requirement of 'java' itself.

These few remaining cases can be easily handled by provenpackager as

Also, my proposal of introducing "java" metapackage (see my other post
in this thread), which would always require the latest JDK, solves this
problem in a different way, without modifying ordinary Java packages at all.

Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk

More information about the devel mailing list