On 02/24/2015 04:36 PM, Deepak Bhole wrote:
* Mikolaj Izdebski <mizdebsk(a)redhat.com> [2015-02-24 10:12]:
> On 02/24/2015 04:06 PM, Deepak Bhole wrote:
>> * Mikolaj Izdebski <mizdebsk(a)redhat.com> [2015-02-24 09:58]:
>>> On 02/24/2015 03:32 PM, Deepak Bhole wrote:
>>>> * Dominik 'Rathann' Mierzejewski <dominik(a)greysector.net>
[2015-02-24 09:29]:
>>>>> On Tuesday, 24 February 2015 at 15:09, Deepak Bhole wrote:
>>>>>> * Dominik 'Rathann' Mierzejewski
<dominik(a)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