F22 System Wide Change: Legacy implementations of the Java platform in Fedora
mizdebsk at redhat.com
Tue Feb 24 16:21:36 UTC 2015
On 02/24/2015 04:59 PM, Pete Travis wrote:
> On Feb 24, 2015 8:32 AM, "Mikolaj Izdebski" <mizdebsk at redhat.com> wrote:
>> On 02/24/2015 02:17 PM, Aleksandar Kurtakov wrote:
>>>> I would much rather live without any legacy jdk, and if so then
> without any
>>>> rules. But not setting
>>>> them will bring chaos for majority of users.
>>> I have a question: Is there anybody that stepped in to maintain the
> legacy jdk?
>>> If there is nobody to maintain it trying to come up with this
> guidelines now would be pointless.
>>> In short I think that such guidelines would better be created *only*
> when there are interested parties, jointly with them and the process is
> played a bit by some copr repo or similar. Purely theoretical work is not
>> I fully agree with Alex here.
>> I would add that if someone really wants to maintain older JDK in Fedora
>> then it should up to *them* to come up with a solution that will work
>> and satisfy expectations of JKD maintainers and Java SIG. Maintaining
>> package is more than clicking "unorphan" in pkgdb.
>> Mikolaj Izdebski
>> Software Engineer, Red Hat
>> IRC: mizdebsk
> If some third party supplies 'java' as the $legacy jdk, and the user
> installs a Fedora package built on $current jdk, which provider will win,
> and what packages will break?
It's implementation detail of different package management systems
(yum/dnf etc) and in general it's unspecfied. My experience shows that
multiple packages providing the same thing are unreliable in practice
and best avoided.
> If the user uses alternatives to set the jdk (that applies here, right?)
> any applications that need one version or the other could break?
Particular applications can be configured to use different JRE/JDK
versions (for example you can run Maven with Java 8, but Ant with Java
7). Per-user configuration is also possible (user bob runs Maven with
Java 8, but fred with Java 7). Fedora is quite flexible in this aspect.
Moreover, Fedora can be configured not to use alternatives for Java
apps, so you can have /usr/bin/java pointing to old JDK while Fedora
applications are running with default (latest) JDK.
> I understand these are relatively ignorant questions, but if the aim is to
> provide a path for someone to maintain older JDKs it seems better to offer
> them guidelines and best practices instead of "you'd better be competent
> enough to figure it out". They might not think of all the potential
If someone wants to maintain old JDK they are free to do so. Moreover,
they will surely get help from Java SIG with implementing that, provided
they show enough involvement. But IMO packaging guidelines is not a
place for listing details how compat packages for JDK should look like.
Software Engineer, Red Hat
More information about the devel