Bug 1344059

These commands worked in RHEL 6 but do *not* work in RHEL 7:

$ sudo alternatives --set java /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java
$ sudo alternatives --set java /usr/lib/jvm/jre-1.8.0-openjdk.x86_64/bin/java

In RHEL 7 you must run:

$ sudo alternatives --set java /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.101-2.6.6.1.el7_2.x86_64/jre/bin/java
$ sudo alternatives --set java /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.91-0.b14.el7_2.x86_64/jre/bin/java

Note that those paths contain the full version and release of the RPM which changes frequently.

The /usr/lib/jvm/jre-1.7.0-openjdk and /usr/lib/jvm/jre-1.8.0-openjdk symlinks still exist but update-alternatives does not list them

This is intentional change against rhel6. You will find plenty of duplicate bugzillas on this topic.

The reason is, that you are allowed to have similar *same* versions of same JDK. This is called multile-jdks and was feature for rhel7.

AFAIK there is no guarantee to transfer random commands form rhel6 to rhel7. Also you can easily adapt this script to read the NVRA value, and then set NVRA the value.

If this is a feature is is extremely unbaked and causing more harm than good.

First off, how is multiple-JDKs (of the same major release) a RHEL 7 feature when you can't use Yum to install multiple versions of the packages at the same time?  Using "rpm" directly breaks the Yum DB and goes against Red Hat's own product documentation.

You say that you can "easily adapt this script to read the NVRA", but 1) no one said anything about a script and 2) you don't provide an example.  Not everything in life is a shell script.  For example, this issue affects Docker containers.  You can't say something like "RUN alternatives --set java /usr/lib/jvm/$(rpm -q java-1.8.0-openjdk)/bin/java" in your Dockerfile because Docker won't parse the $().

(In reply to Jason Bradley Nance from comment #4)
> If this is a feature is is extremely unbaked and causing more harm than good.
> 
Thats your opinion I cant share.

> First off, how is multiple-JDKs (of the same major release) a RHEL 7 feature
> when you can't use Yum to install multiple versions of the packages at the
> same time?  Using "rpm" directly breaks the Yum DB and goes against Red
> Hat's own product documentation.

Unluckily I can agree on this.

> 
> You say that you can "easily adapt this script to read the NVRA", but 1) no
> one said anything about a script and 2) you don't provide an example.  Not

basename `echo  /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.*x86_64/` ?

> everything in life is a shell script.  For example, this issue affects
> Docker containers.  You can't say something like "RUN alternatives --set
> java /usr/lib/jvm/$(rpm -q java-1.8.0-openjdk)/bin/java" in your Dockerfile
> because Docker won't parse the $().

as above. 


The alternatives name is not an bug its feature - however you may disagree.

>> You say that you can "easily adapt this script to read the NVRA", but 1) no
>> one said anything about a script and 2) you don't provide an example.  Not

> basename `echo  /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.*x86_64/` ?

This also does not work in a Dockerfile for the same reasons that $() doesn't work.

I guess it at least accept $VARIABLES,  Still this is not an, please deal with it or go by support path.

> I guess it at least accept $VARIABLES

Example?  AFAIK there is no way to set variables in a Dockerfile by storing the results of a command.

> Still this is not an, please deal with it or go by support path.

First off, you yourself stated that there are multiple BZs for this which shows that your customers are speaking and Red Had is ignoring their voices.  Secondly, this is a paid support case --> 01647944

(In reply to Jason Bradley Nance from comment #8)
> > I guess it at least accept $VARIABLES
> 
> Example?  AFAIK there is no way to set variables in a Dockerfile by storing
> the results of a command.
> 
> > Still this is not an, please deal with it or go by support path.
> 
> First off, you yourself stated that there are multiple BZs for this which

And all were discussed and closed.

> shows that your customers are speaking and Red Had is ignoring their voices.
> Secondly, this is a paid support case --> 01647944

ok. Sorry. I will code what upper classes will decide of course.

Jiri,

I've asked Chris Williams and Chris VanHoof to look in to this.

Hi Joe, Jason,

The alternatives are settable statically through another master alternative link created during install. You can use:

alternatives --set java `readlink -f /etc/alternatives/jre_1.7.0_openjdk/bin/java`

and

alternatives --set java `readlink -f /etc/alternatives/jre_1.8.0_openjdk/bin/java`

To set the alternatives to Java 7 or 8 respectively, without having to provide the exact NVR.

This is also usable in docker as:

RUN bash -c 'alternatives --set java `readlink -f /etc/alternatives/jre_1.7.0_openjdk/bin/java`'


I have verified in a VM and in docker that both of the above approaches work.



Can you please confirm that this workaround is sufficient?

While this technically works for the Docker example I do not consider it a sufficient workaround.  It is a kludge (though, admittedly, maybe more so due to Docker limitations in this instance) that does not address the core issue, which is that Red Hat is not providing a way to simply tell the OS to use OpenJDK 7/8/N.  That functionality has existed in RHEL for over a decade.

We should not have to come up with a workaround for every iteration of automation platform.  Furthermore, this is being caused by a horrible implementation of "multiple, concurrent Java of the same major version".  You are going against your own standards/best practices/documented processes and have "fixed" one problem by causing another.

Why can't the symlinks that already exist to the major versions by registered as an alternative as they have been for multiple releases of RHEL?

(In reply to Jason Bradley Nance from comment #14)
> While this technically works for the Docker example I do not consider it a
> sufficient workaround.  It is a kludge (though, admittedly, maybe more so
> due to Docker limitations in this instance) that does not address the core
> issue, which is that Red Hat is not providing a way to simply tell the OS to
> use OpenJDK 7/8/N.  That functionality has existed in RHEL for over a decade.
> 
> We should not have to come up with a workaround for every iteration of
> automation platform.  Furthermore, this is being caused by a horrible
> implementation of "multiple, concurrent Java of the same major version". 
> You are going against your own standards/best practices/documented processes
> and have "fixed" one problem by causing another.
> 

For the record, parallel JDK installation was explicitly requested of us; usually used by Middleware developers to assess performance changes or bugs, or run multiple Middleware apps with different JDKs, on the same system.

> Why can't the symlinks that already exist to the major versions by
> registered as an alternative as they have been for multiple releases of RHEL?

They cannot exist statically because it is a limitation of the alternative system. For parallel JDKs to exist on the system, they need to be installed in a unique path. For the path to be usable via alternatives, an explicit path needs to be provided. Since uniqueness is a requirement, the only way to do it is to have the NVR in the path.

Technically there are some very bad hacks we can do to make the path static (there are always 'ways'), but that will risk breaking many other things.

The method specified in comment #13 is perfectly static and does provide a consistent way to switch between JDK 7/8/N and it is no more a kludge than using /usr/lib/jvm/jre-1.8.0-openjdk.x86_64 (it is just a change in path). It is indeed messier on Docker, but as you stated, that is more of a limitation of Docker.

We have provided a workaround for the Docker limitation; what else do you propose we do?

(In reply to Deepak Bhole from comment #15)
> For the record, parallel JDK installation was explicitly requested of us;
> usually used by Middleware developers to assess performance changes or bugs,
> or run multiple Middleware apps with different JDKs, on the same system.

I'm not arguing against this ability, I'm arguing against the method by which it was implemented.  Furthermore, you have pitted your customers against each other.

> Technically there are some very bad hacks we can do to make the path static
> (there are always 'ways'), but that will risk breaking many other things.
> 
> The method specified in comment #13 is perfectly static and does provide a
> consistent way to switch between JDK 7/8/N and it is no more a kludge than
> using /usr/lib/jvm/jre-1.8.0-openjdk.x86_64 (it is just a change in path).
> It is indeed messier on Docker, but as you stated, that is more of a
> limitation of Docker.
> 
> We have provided a workaround for the Docker limitation; what else do you
> propose we do?

I have already stated very clearly what I want done.  Your chosen method for implementing parallel JDK has broken the alternatives system.  No other use of this requires knowledge of the full NVR, and neither did previous versions of RHEL.  Why not simply maintain a symlink to the latest major version and register it as was done previously (such as was done on RHEL 6 with OpenJDK 6 and 7)?  It would be simple to have the scriptlets of the OpenJDK RPMs "refresh" these links any time a package was installed/removed.

(In reply to Jason Bradley Nance from comment #16)
> (In reply to Deepak Bhole from comment #15)
> > For the record, parallel JDK installation was explicitly requested of us;
> > usually used by Middleware developers to assess performance changes or bugs,
> > or run multiple Middleware apps with different JDKs, on the same system.
> 
> I'm not arguing against this ability, I'm arguing against the method by
> which it was implemented.  Furthermore, you have pitted your customers
> against each other.
> 
> > Technically there are some very bad hacks we can do to make the path static
> > (there are always 'ways'), but that will risk breaking many other things.
> > 
> > The method specified in comment #13 is perfectly static and does provide a
> > consistent way to switch between JDK 7/8/N and it is no more a kludge than
> > using /usr/lib/jvm/jre-1.8.0-openjdk.x86_64 (it is just a change in path).
> > It is indeed messier on Docker, but as you stated, that is more of a
> > limitation of Docker.
> > 
> > We have provided a workaround for the Docker limitation; what else do you
> > propose we do?
> 
> I have already stated very clearly what I want done.  Your chosen method for
> implementing parallel JDK has broken the alternatives system.  No other use
> of this requires knowledge of the full NVR, and neither did previous
> versions of RHEL.  Why not simply maintain a symlink to the latest major
> version and register it as was done previously (such as was done on RHEL 6
> with OpenJDK 6 and 7)?  It would be simple to have the scriptlets of the
> OpenJDK RPMs "refresh" these links any time a package was installed/removed.

A link to the latest JDK and registering that as an alternative breaks the ability to use an older JDK via alternatives. The only way to keep both features (with changes limited to OpenJDK packages) is to use a very complex dual layer of alternatives which would be a risky change.

I have been giving this some thought over the past couple of days and I think the most ideal and stable way to fix this would be to update the alternatives code itself to de-reference target links. 

I have created a patch for it and opened a new bug, bug#1346456. I cannot guarantee that it will be accepted by the chkconfig maintainer, but I will try to work with them to get it in. If that change goes in, the old way that works on RHEL-6 should continue to work on RHEL-7 without any changes to the OpenJDK package.

> 
> I have created a patch for it and opened a new bug, bug#1346456. I cannot
> guarantee that it will be accepted by the chkconfig maintainer, but I will
> try to work with them to get it in. If that change goes in, the old way that
> works on RHEL-6 should continue to work on RHEL-7 without any changes to the
> OpenJDK package.


Will this not mean, that multiple JDKS will appear like thisin config?

There are 4 programs which provide 'java'.

  Selection    Command
-----------------------------------------------
*+ 1           /usr/lib/jvm/java-1.8.0-openjdk/jre/bin/java
   2           /usr/lib/jvm/java-1.8.0-openjdk/jre/bin/java
   3           /usr/lib/jvm/java-1.8.0-openjdk/jre/bin/java
   4           /usr/lib/jvm/java-1.7.0-openjdk/jre/bin/java

at the end?

So maybe some additional switch to alternatives' --config option like --derefference?

(In reply to jiri vanek from comment #18)
> > 
> > I have created a patch for it and opened a new bug, bug#1346456. I cannot
> > guarantee that it will be accepted by the chkconfig maintainer, but I will
> > try to work with them to get it in. If that change goes in, the old way that
> > works on RHEL-6 should continue to work on RHEL-7 without any changes to the
> > OpenJDK package.
> 
> 
> Will this not mean, that multiple JDKS will appear like thisin config?
> 
> There are 4 programs which provide 'java'.
> 
>   Selection    Command
> -----------------------------------------------
> *+ 1           /usr/lib/jvm/java-1.8.0-openjdk/jre/bin/java
>    2           /usr/lib/jvm/java-1.8.0-openjdk/jre/bin/java
>    3           /usr/lib/jvm/java-1.8.0-openjdk/jre/bin/java
>    4           /usr/lib/jvm/java-1.7.0-openjdk/jre/bin/java
> 
> at the end?
> 
> So maybe some additional switch to alternatives' --config option like
> --derefference?

No, the de-referencing is only done when --set is called. Alternatives will still use the full NVR path when they are created, and they would have no way of knowing what all is pointing to a target. The alternatives change I have proposed only changes behavior of --set, it makes it so that you can use:

alternatives --set <master> <symlink>  , or, 
alternatives --set <master> <target>

where <symlink> is a link to <target>, then behavior of both above will be identical.

> I have been giving this some thought over the past couple of days and I
> think the most ideal and stable way to fix this would be to update the
> alternatives code itself to de-reference target links. 


One idea crossed my mind. In 7.3 we will be introducing an --family switch, which have values java-1.{6,7,8}.0-{openjdk,oracle,ibm}

So what about this:
 - if only one jdk form given family is there, instead of NVRA show family
 - if more jdks of same family is in system, show NVRA
 - the selection can be done by NVRA or family. If family is used, then latest (by priority of given family) is selected.

It still needs some patching of alternatives.

(In reply to jiri vanek from comment #20)
> > I have been giving this some thought over the past couple of days and I
> > think the most ideal and stable way to fix this would be to update the
> > alternatives code itself to de-reference target links. 
> 
> 
> One idea crossed my mind. In 7.3 we will be introducing an --family switch,
> which have values java-1.{6,7,8}.0-{openjdk,oracle,ibm}
> 
> So what about this:
>  - if only one jdk form given family is there, instead of NVRA show family
>  - if more jdks of same family is in system, show NVRA
>  - the selection can be done by NVRA or family. If family is used, then
> latest (by priority of given family) is selected.
> 
> It still needs some patching of alternatives.

Hmm, that sounds interesting. Can you give an example of how this will work?

there are cheated assumptions from fedora:

Every alternatives master have one additional information --family java-1.8.0-openjdk - http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/tree/java-1.8.0-openjdk.spec#n271 :

alternatives \\
  --install %{_bindir}/java java %{jrebindir %%1}/java $PRIORITY  --family %{name} \\
  --slave %{_jvmdir}/jre jre %{_jvmdir}/%{jredir %%1} \\

This change will need to go to each jdk (as we are planing anyway, as --fmaily fixed https://bugzilla.redhat.com/show_bug.cgi?id=1251560 )

My alternatives looks like this now:

alternatives --config java
There are 4 programs which provide 'java'.
  Selection    Command
-----------------------------------------------
*+ 1           /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.92-1.b14.fc23.x86_64/jre/bin/java
   2           /usr/lib/jvm/java-1.7.0-openjdk-legacy-1.7.0.101-2.6.6.1.fc23.x86_64/jre/bin/java
   3           /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.92-1.b14.fc23.x86_64-debug/jre/bin/java
   4           /usr/lib/jvm/java-9-openjdk-9.0.0.116-1.fc23.x86_64/bin/java

  And I need to type:
alternatives --set java /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.92-1.b14.fc23.x86_64-debug/jre/bin/java
  to set it.

Fact, that there is some family guarding manual selection among mayor version is visible only via:
cat /var/lib/alternatives/java  | grep "@"
@java-1.8.0-openjdk@1800092
@java-1.8.0-openjdk@1800091
#@family@priority@


Now assume that all jdks got the family inspired by openjdk8 and the patch I sugested is implemented as I wrote. Then my alternatives will print out:
alternatives --config java
There are 4 programs which provide 'java'.
  Selection    Command
-----------------------------------------------
*+ 1           /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.92-1.b14.fc23.x86_64/jre/bin/java
   2           java-1.7.0-openjdk
   3           /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.92-1.b14.fc23.x86_64-debug/jre/bin/java
   4           java-9-openjdk

7 and 8 are showing their familyas they are alone in theirs mayor version.
But Because I have two versions of openjdk8, it hsouws NVRA However if I delete  the debug version, they will state:

There are 3 programs which provide 'java'.
  Selection    Command
-----------------------------------------------
*+ 1           java-1.8.0-openjdk
   2           java-1.7.0-openjdk
   3           java-9-openjdk


In both cases, the set via NVRA and via family will work. Second case is trivial, but the first:
  alternatives --set java java-9-openjdk 
will select /usr/lib/jvm/java-9-openjdk-9.0.0.116-1.fc23.x86_64/bin/java
  alternatives --set java java-1.7.0-openjdk-legacy
will select usr/lib/jvm/java-1.7.0-openjdk-legacy-1.7.0.101-2.6.6.1.fc23.x86_64/jre/bin/java
  alternatives --set java java-1.8.0-openjdk
will select /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.92-1.b14.fc23.x86_64/jre/bin/java , because it have higher priority then my second JDK8

Of course I can always type
  alternatives --set java  /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.92-1.b14.fc23.x86_64-debug/jre/bin/java
to select exact JDK


I see several issues with this apporach, form whose some will fly away if also yours patch is in:
 - biggest issue is, that the family is "just string" so there can be human error during packaging
 - multilib will suffer, as architecture is not (and cannot be) included in family. So once you have same version of 64B jdk and 32B jdk, you are back on NVRA (and even better, those two have same priority, so the selection via family will be indeterministic)
   - IIUC your patch, then it can help in this case

s/7 and 8 are showing their familyas they are alone in theirs mayor version./7 and 9 are showing their families they are alone in theirs mayor version.

Is the whole reasoning for adding --family just to allow setting of alternatives statically to 7/8/9? If so, I think 1346456 is the right fix. We have already made too many changes leading to incompatibilities. I would prefer not to add another one.

(In reply to Deepak Bhole from comment #24)
> Is the whole reasoning for adding --family just to allow setting of
> alternatives statically to 7/8/9? If so, I think 1346456 is the right fix.


Oh no. --family is solveing: https://bugzilla.redhat.com/show_bug.cgi?id=1291340#c1

This would be another benefit which it may bring. Causing no backward incompatibility  but making work with alternatives *much* more friendly.

(In reply to Jason Bradley Nance from comment #14)
> While this technically works for the Docker example I do not consider it a
> sufficient workaround.  It is a kludge (though, admittedly, maybe more so
> due to Docker limitations in this instance) that does not address the core
> issue, which is that Red Hat is not providing a way to simply tell the OS to
> use OpenJDK 7/8/N.  That functionality has existed in RHEL for over a decade.
> 
> We should not have to come up with a workaround for every iteration of
> automation platform.  Furthermore, this is being caused by a horrible
> implementation of "multiple, concurrent Java of the same major version". 
> You are going against your own standards/best practices/documented processes
> and have "fixed" one problem by causing another.
> 
> Why can't the symlinks that already exist to the major versions by
> registered as an alternative as they have been for multiple releases of RHEL?

Just an update --

We are still debating on best way to fix this. The alternatives fix I proposed will address this, but it is a workaround hack nonetheless

The correct way to fix it I think is an upcoming fix (already scheduled for inclusion in 7.3) that actually adds a new family feature to alternatives.

This feature allow selection of JDK N directly. For example, with:

$ alternatives --config java
There are 3 programs which provide 'java'.
  Selection    Command
-----------------------------------------------
*+ 1           /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.92-1.b14.fc23.x86_64/jre/bin/java
   2           /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.101-2.6.6.1.fc23.x86_64/jre/bin/java
   3           /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.92-1.b14.fc23.x86_64-debug/jre/bin/java

Once can then say: alternatives --set java java-1.8.0-openjdk , or alternatives --set java java-1.7.0-openjdk

to select between latest 7 or 8 versions. With 6 being EOLd in December, we will limit this feature to Java 7 and 8 (Oracle, IBM and OpenJDK)


Jason, does the above satisfy your use case?


And Jiri, is anything I said above incorrect?

With this change if we say:

alternatives --set java java-1.8.0-openjdk

or:

alternatives --set java java-1.7.0-openjdk

...will that point the tool symlinks (java/javac/keytool/etc) in /usr/bin to the latest installed OpenJDK 8 or 7 respectively?  What will happen when an OpenJDK update is applied to the system?

(In reply to Jason Bradley Nance from comment #33)
> With this change if we say:
> 
> alternatives --set java java-1.8.0-openjdk
> 
> or:
> 
> alternatives --set java java-1.7.0-openjdk
> 
> ...will that point the tool symlinks (java/javac/keytool/etc) in /usr/bin to
> the latest installed OpenJDK 8 or 7 respectively? 

Yes, that should be the case. Those binaries already switch with the alternatives now

> What will happen when an OpenJDK update is applied to the system?

Jiri, I don't want to be presumptuous here -- what happens here? e.g. if the user had selected OpenJDK7 (when both 7 and 8 are on the system) and both jdks are then updated to the latest, what will happen?

(In reply to Deepak Bhole from comment #34)

As I have this in mind, the usage of family to be usable also for --set, it will be just placeholder. Which will find latest jdk 8 especially 7(by priority), and --set it.

So once the jdk is selected, during update is will handled in  usual way.

That means - in scope of rhel7.3 where --family does exists,  that during update, once you have manually selected jdk (as happened by calling --set {family} ) any update stay in family. If you had selected jdk7, after update you will have latest jdk7. If you had selcted jdk8, after update you will have latest jdk8 selected. 

In 7.2, where --family does not exists, no meter if you had jdk8 or 7 selected, after update of both, jdk8 will be selected.


Note - if you have multiple jdks installed by RPM, then adding next jdk in RPM way,  do not affect alternatives. So if you had latest jdk selected by {family} and you *add* (not update) newer jdk, then the originally selected jdk will remain.

(In reply to Deepak Bhole from comment #32)
> 
> And Jiri, is anything I said above incorrect?



The simplified view - when only one jdk of family is installed (to hsow ojnly family instead of full NVRA) is not wonted?

(In reply to jiri vanek from comment #36)
> (In reply to Deepak Bhole from comment #32)
> > 
> > And Jiri, is anything I said above incorrect?
> 
> 
> 
> The simplified view - when only one jdk of family is installed (to hsow
> ojnly family instead of full NVRA) is not wonted?

No, it is ok if it shows only family if only one JDK N is installed; it makes it easier to read.

So --config and --set have now prototype workaround in alternatives. as descibed in c#20-c#37

How about --remove ? Imho it should stay in path specifier only. How the reporter see it?

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


They can be immediately tested in fedora (not fnal version of --family), but for rhel the packages supporting --family are in progress

The first elvel of fixes was pushed to alternatives. And packages are built for 7.3 and as fedora udpates.

it would be really nice to see reporters feedback.

I installed the chkconfig from comment 43 on RHEL 7 but missed the part about changes still needed to the OpenJDK packages.  How would you like me to go about testing this on RHEL to provide feedback?

Hello!

This bugzilla was imho fixed by https://bugzilla.redhat.com/show_bug.cgi?id=1349386 which will be in 7.3 I think we may close as fixed next release, but I would rather let reporter to confirm after 7.3 is released (or if he hae hands on beta)

*** This bug has been marked as a duplicate of bug 1349386 ***