I finally got to this one and I don't think that this is a bug. Basically you have chosen a different implementation of something and it does not provide whole functionality. I could imagine that leaving the old link (for example in the case of MTAs) could sometimes break things.

On the other hand, this could be a new functionality wit a new switch (something like like --preserve-missing), would that help in your use-cases?

Indeed. This would help.  But isnt the cost higher then benefit?

Still, "fixing" this, is the only way I come up to fix the https://bugzilla.redhat.com/show_bug.cgi?id=1312019

See

https://bugzilla.redhat.com/show_bug.cgi?id=1344059#c40
https://bugzilla.redhat.com/show_bug.cgi?id=1344059#c41

There are rpms with experimental fix in:
https://jvanek.fedorapeople.org/chkconfig/perists%20and%20family%20in%20config%20and%20set/v1/


Currently there is no real package supporting this, but I will add it to experimental branch of openjdk8 Thanx!

(In reply to jiri vanek from comment #5)
> See
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1344059#c40
> https://bugzilla.redhat.com/show_bug.cgi?id=1344059#c41

Hello! The fix is in a bit different meter Then I though. Although it is alos posible workaround (benefit is that there is no need to configure existing packages, and that user is doing this intentionally )

What I had in mind was:

 alternatives \\
   --install %{_bindir}/java java %{jrebindir %%1}/java $PRIORITY  --family %{name}.%{_arch} \\
   --slave %{_jvmdir}/jre jre %{_jvmdir}/%{jredir %%1} \\
   --slave %{_jvmjardir}/jre jre_exports %{_jvmjardir}/%{jrelnk %%1} \\
-  --slave %{_bindir}/jjs jjs %{jrebindir %%1}/jjs \\
+  --slave %{_bindir}/jjs jjs %{jrebindir %%1}/jjs  --persists \\
   --slave %{_bindir}/keytool keytool %{jrebindir %%1}/keytool \\

And then the slave of jjs will be handled as you do in  --keep-missing 
The advantage of this is that only special, expected slaves are kept. Another benefitis that it works over --config or already existing tools like system-switch-java

However I like your approach. It is more safe. What about combination?

alternatives  --keep-missing --set TEST /tmp/tmp.CuACTutoSW/link_a/main

 - will keep all missing slaves - no meter of status of --persists

alternatives  --remove-missing --set TEST /tmp/tmp.CuACTutoSW/link_a/main

 - will remove all missing slaves - no meter of status of --persists (backward comaptibility)

alternatives --set TEST /tmp/tmp.CuACTutoSW/link_a/main  OR   alternatives --config TEST

 - will keep only slaves with --persists  flag


I'm a bit afraid f genral usage of --keep-missing  - on one side is really good that it is user-intentional.  On second there are java-vendor specific bninaries, whih may be really unexpected to persists.

Thoughts?

Lukas, thnak you for the initial version. the testing is much more compfrtbale.
Also lukas, do you mind to elaborate on devel/qa+?  I hope to ack  1312019.

For record - I think that even wit simple --keep-missing I can provie /usr/bin/jjs  so I can proceed with original bug.

As --persists is affecting alternatives config files, it will be subject of another discussion later, once plumbers have more time.

The inclusion of --persists have one more usecase:

Lets say I have jdk7 installed, and alternatives are manually on it.
So I install jdk8. It will notget selected (although it have higher priority, but I Have 7 manually)
But jjs have --persists flag. In this case. the persisting slave should be set.

It leads to cornercase:
Lets say I have jdk7 and 9 installed, and alternatives are manually on it.
I had 9 selected. It provides jjs. I switch to jdk7. It do not. But considering any of approaches in this bug implemented, I switched to 7, so 9's jjs stayed linked.
Now I install 8 as in first paragraph. jjs should switch according to priority.
if newly come jdk8's master of jjs priority is higher then the one of jdk9, it should switch. Else jjs from jdk9 should stay selected.

So for now we will just go with the new --keep-missing option.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2467.html