F22 System Wide Change: Legacy implementations of the Java platform in Fedora
mitr at redhat.com
Wed Feb 25 17:58:17 UTC 2015
> On 02/24/2015 06:41 PM, Miloslav Trmač wrote:
> > Hello,
> >> "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),
> > AFAIK nothing obsoletes a package just because it is orphaned…
> If no volunteer shows up for maintenance of old JDK then it would be
> deprecated and obsoleted, as it's was done with previous JDK packages.
How would that work _exactly_?
1. JDK-(N+1) is first shipped. The maintainer of JDK-N intends not to package it, so JDK-(N+1) includes Obsoletes:JDK-N from the start.
2. Someone revives JDK-N. Oops, it cannot be installed because JDK-(N+1) obsoletes it.
3. JDK-(N+1) is updated to remove the Obsoletes: . Oops, upgrades from older Fedora versions will no longer remove JDK-N for users who didn’t ask for the legacy version.
This is the problem that the renaming to -legacy is supposed to prevent. Though, perhaps it would work equally well to have Obsoletes:JDK-N < $version-($release+1); this would still allow updating the older Fedora with bug fixes for JDK-N but to be removed on upgrade, as long as the $release number is kept low enough. And the possible -legacy package could then be represented simply by shipping a version with a bigger $release.
More information about the devel