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

Mikolaj Izdebski mizdebsk at redhat.com
Tue Feb 24 16:04:18 UTC 2015

On 02/24/2015 04:36 PM, Deepak Bhole wrote:
> * Mikolaj Izdebski <mizdebsk at redhat.com> [2015-02-24 10:12]:
>> 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
>> mass-change.
>> 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.
> Ah, I had missed that. Yes, the metapackage solution should work to the
> same effect. I don't know if we can just call it 'java' though, unless
> you are proposing that 'java' provision be removed from current openjdk
> packages?

I'm not really proposing as I haven't thought about this much yet, but
the idea was about be adding a few empty binary packages "java",
"java-devel", "java-headless" and so on (they could be subpackages of
javapackages-tools). Existing provides with the same names could be
removed from JDK packages.

"java" would be the preferred JRE in Fedora. The package would have no
content, but it would have Requires on preferred Fedora JRE, currently
java-1.8.0-openjdk. This could be easily changed as default JRE changes.
The same is for other binary subpackages of "java", respectively.

All system packages would require subpackages of "java" as they do now
(unless there is good reason not to). Users that install "java" would
get latest JRE, which would be updated to new major versions as they
become default. Older JDKs would not be removed during update (unless
there is no maintainer and they are obsoleted as currently), but users
could remove them with "yum autoremove", unless something requires older
JDK or they installed it explicitly.

Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk

More information about the devel mailing list