> 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.
Mirek
--
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
