Description of problem: Version-Release number of selected component (if applicable): libreadline-java-0.8.0-38.fc22.x86_64 How reproducible: Every time Steps to Reproduce: 1. Install libreadline-java-0.8.0-38.fc22.x86_64 Actual results: /usr/lib64/libreadline-java/libreadline-java.jar is a stale symbolic link to the nonexistent file ../java/libreadline-java.jar Expected results: /usr/lib64/libreadline-java/libreadline-java.jar to be a valid symbolic link Additional info: /usr/lib64/libreadline-java/libreadline-java.jar should be a symbolic link to ../../lib/java/libreadline-java.jar
libreadline-java-0.8.0-42.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-5acd868ee7
libreadline-java-0.8.0-42.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-5acd868ee7
libreadline-java-0.8.0-42.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Pushing it to Fedora 23 doesn't help the people that are running Fedora 22. If I wanted a fix for Fedora 23, I would have filed the bug against Fedora 23. I guess it doesn't matter, as I'm looking for a new distribution, because Fedora has made several changes that have made Fedora more Windows-like and less Unix-like (apparently) to appeal to gamers and other standalone users, has dropped a lot of networking support, doesn't update the documentation, and hasn't been worth a crap as a server distribution since Fedora 14.
(In reply to Roy A. Gilmore from comment #0) > Actual results: > /usr/lib64/libreadline-java/libreadline-java.jar is a stale symbolic link to > the nonexistent file ../java/libreadline-java.jar > > Expected results: > /usr/lib64/libreadline-java/libreadline-java.jar to be a valid symbolic link > > Additional info: > /usr/lib64/libreadline-java/libreadline-java.jar should be a symbolic link > to ../../lib/java/libreadline-java.jar No, this will never happen The artifact is installed in /usr/lib/java (%{_jnidir}) see https://fedoraproject.org/wiki/Packaging:Java#Packaging_JAR_files_that_use_JNI
For the rest, your considerations do not matter to anyone. keep them for yourself or for your cronies spree. Thanks.
(In reply to gil cattaneo from comment #5) > (In reply to Roy A. Gilmore from comment #0) > > > Actual results: > > /usr/lib64/libreadline-java/libreadline-java.jar is a stale symbolic link to > > the nonexistent file ../java/libreadline-java.jar > > > > Expected results: > > /usr/lib64/libreadline-java/libreadline-java.jar to be a valid symbolic link > > > > Additional info: > > /usr/lib64/libreadline-java/libreadline-java.jar should be a symbolic link > > to ../../lib/java/libreadline-java.jar > No, this will never happen > The artifact is installed in /usr/lib/java (%{_jnidir}) > see > https://fedoraproject.org/wiki/Packaging: > Java#Packaging_JAR_files_that_use_JNI The example I gave is (from a filesystem view) a valid location for the target of the symbolic link. I don't really care about packaging policy, that is an administrative detail that is important to packagers (and should be), not users. What I do care about, is that a broken symbolic link should not exist in a released package, and should have been caught by QA. Where that link actually points may very well be a policy issue, but, the target should exist regardless.