----- Original Message -----
From: "Mikolaj Izdebski" <mizdebsk(a)redhat.com>
To: devel(a)lists.fedoraproject.org
Sent: Wednesday, February 25, 2015 11:14:35 AM
Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in
Fedora
On 02/24/2015 04:06 PM, Jiri Vanek wrote:
> On 02/24/2015 04:03 PM, Mikolaj Izdebski wrote:
>> On 02/24/2015 03:51 PM, Mikolaj Izdebski wrote:
>>>> 2.) Ensure dist upgrades remove old JDK package (which may no longer
>>>> get security updates).
>>>
>>> Firstly, as I understand upgrade isn't supposed to remove packages by
>>> default, unless they are obsoleted or conflict with something. Are you
>>> saying that JDKs should be treated exceptionally by package management
>>> systems?
>>
>> I should add that user can easily remove packages which were installed
>> as dependencies, but which are no longer needed by running "yum
>> autoremove" command.
>>
>
> So by other words - from option "one" and "two" you vote for
two, no
> renaming, and removing rules 4,5,6,7.
Technically I'm against this change, see my first post.
> You do not complain about rule 2 and 3.Right?
Rule 2 is definitely a good thing. Muliple providers of the same thing
don't work in practice, so we should have only one package providing
"java" etc.
I don't know the exact scheme used for priorites, so I can't comment on
rule 3. I trust you to set priorities correctly so that "main JDK" has
highest priority. Lecacy and tech-preview JDKs should IMO have lower
priority.
I would even say that legacy(even any) JVMs should not use the alternatives system at all.
I still remember the fun of having kaffe, jamvm, gcj.. with their own priorities,
alternatives (java/javac/jar..) going out of sync and etc. This was a nightmare to
support and it was causing more damage than helping. Using legacy JVM should be done using
the tools that provide more isolation nowadays like scl to prevent these problems.
Alexander Kurtakov
Red Hat Eclipse team
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:
http://fedoraproject.org/code-of-conduct