Description of problem: I cannot choose java with the alternatives command anymore. If I want to choose the java version with the alternatives command there is an error message that the file exists. Of course the file exists - why is this a problem? [root@bat alternatives]# alternatives --config java There are 2 programs which provide 'java'. Selection Command ----------------------------------------------- * 1 /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b12-8.fc29.x86_64/bin/java 2 /usr/lib/jvm/java-11-openjdk-11.0.1.13-1.fc29.x86_64/bin/java Enter to keep the current selection[+], or type selection number: 1 failed to link /usr/bin/java -> /etc/alternatives/java: File exists When I remove /etc/alternative/java there is an error message that the file is missing. root@bat alternatives]# rm java [root@bat alternatives]# alternatives --config java failed to read link /usr/bin/java: No such file or directory [root@bat alternatives]# alternatives --config java failed to read link /usr/bin/java: No such file or directory To have a working java the only option I saw was to set the link manually. ln -s /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b12-11.fc29.x86_64/bin/java /etc/alternatives/java Version-Release number of selected component (if applicable): chkconfig-1.10-6.fc29.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: I cannot use alternatives to set the java binary. Expected results: I should be able to choose my java with alternatives. Additional info: Fedora 29 Silverblue
The problem was in unlinking /usr/bin/java instead of /etc/alternatives/java and also bad path linking due to this problem. The bug will be probably fixed in the next release. We should wait what the maintainer will say about the fix.
That part of code should be improved a bit but this is not the problem here. The way how the rpm-ostree in silver-blue work is incompatible with alternatives. The main issue is that the alternative database in /var is not created at all. This can't be solved in the alternatives, you need to file an issue about this behaviour to silverblue directly https://pagure.io/fedora-silverblue/issues
FWIW I think alternatives could fix this by storing state in /etc solely and not using /var. As I noted on an internal mailing list, this isn't *just* an ostree issue; any system which tries to "snapshot" the OS or do offline updates, without capturing/snapshotting user data (i.e. /var) would trip over this too.
I think Colin's proposed fix is the way to go with this; created https://github.com/fedora-sysv/chkconfig/issues/27 for better visibility upstream.