Re: [Oorexx-devel] update-alternatives (Re: [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

[Rony G. Flatscher]

update-alternatives/alternatives is a long established standard in the Linux 
world and deployed in
all major systems, e.g.

  * https://wiki.debian.org/DebianAlternatives ("the father" of 
update-alternatives)
  * https://www.redhat.com/sysadmin/alternatives-command
  * https://software.opensuse.org/package/update-alternatives

Java on Linux usually uses update-alternatives and is therefore a very good 
citizen in the Linux
world. It is also a nice showcase for complex installations from different 
sources and different
versions that co-exist without a problem. Changing the default Java is a breeze 
and stable.

If we want ooRexx to be a good citizen on Linux we should support 
update-alternatives/alternatives
on Linux systems. It will also allow the fellow Regina Rexx interpreter to 
co-exist on the same
installation. One can have different versions in different bitnesses (32, 64) 
installed at the same
time of all of these Rexx interpreters. One can use them individually by 
running their executable
from different installation directories (became possible with ooRexx 5).

But most important, it becomes easy and with practical no overhead (no fiddling 
around with the
environment) to change the default system Rexx interpreter to any of the Rexx 
interpreters
maintained by update-alternatives/alternatives at any moment, back and forth, 
allowing testing,
experimenting applications with all the different Rexxes.

Having had the support in the Linux installer, but with an erroneous 
side-effect that according to
Mark - if he had been aware of the problem - could have been fixed long ago, 
which means it can be
fixed also now or in the near future.

So my request is to get update-alternatives/alternatives back into the Linux 
package installation
definitions, once the current work on Linux installers has concluded, assuming 
in the days, maybe
weeks to come. With the help of Mark and of Enrico this should be a feasible 
and welcome feature for
ooRexx 5 on Linux, without distracting resources or holding up a release.

---rony


On 07.04.2020 13:32, René Jansen wrote:
> it is great if it works but it is def old skool. This is the type of work 
> (evaluating code against releases of whatever) that anyone I work with (yes, 
> very young people, well compared to us) would do in a docker container.
> I am a bit worried about the release schedule (what release schedule?) but I 
> am ok with either fixing or postponing it, not really with spending a lot of 
> time on it.
>
>  With the documentation going well we should try to avoid breaking change and 
> focus on showstoppers IMHO.
>
> René.
>
>> On 7 Apr 2020, at 13:11, Rony  wrote:
>>
>> It may be true that one can individually change the ooRexx location and 
>> version by changing PATH such that the operating system can find the desired 
>> ooRexx in that particular session that changed the PATH to point to a 
>> different ooRexx.. (This ability will not be lost if supporting 
>> update-atlernatives on Linux, rather new possibilities of installation 
>> combinations that do not break alternate installations becomes possible on 
>> Linux.)
>>
>> However, this is not matching what update-alternatives defines and allows 
>> for:

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] update-alternatives (Re: [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

[P.O. Jonsson]

Dear Rony,

I understand that there is a use case for the „switch" and if someone with 
sufficient expertise can bring it back to CMakeLists.txt without breaking other 
things I have no objections but PLEASE do these changes only next week, ok? The 
rollback broke a number of other things for the Linux distributions (like the 
missing package version number), until these things are found and mended it 
would be very helpful if CMakeLists.txt stayed as it is for a few days (at 
least in this corner).

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se



> Am 07.04.2020 um 13:11 schrieb Rony :
> 
> It may be true that one can individually change the ooRexx location and 
> version by changing PATH such that the operating system can find the desired 
> ooRexx in that particular session that changed the PATH to point to a 
> different ooRexx.. (This ability will not be lost if supporting 
> update-atlernatives on Linux, rather new possibilities of installation 
> combinations that do not break alternate installations becomes possible on 
> Linux.)
> 
> However, this is not matching what update-alternatives defines and allows for:
> - parallel installations of the same software in different versions,
> - parallel installations of the equivalent software by different groups and 
> vendors,
> - listing of all of the alternative installations,
> - making one of the alternatives the system default, such that no one has to 
> fiddle with PATH settings in any session,
> - maintaining the alternative packages.
> 
> This is not a service that developers of a certain package need like the ones 
> on this list, rather it is a service for deploying and for the „customers“ of 
> such packages that may be provided by different sources.
> 
> Personally, I have come to respect and admire this feature (as a huge time 
> saver) on Linux regarding my work on BSF4ooRexx for which I need different 
> versions of Java present in order to become able to test BSF4ooRexx on them. 
> One reason being that BSF4ooRexx needs to work on Java 1.6/6 (current Java 
> baseline) which is still deployed in companies, where the latest Java carries 
> the version 14 since a few weeks! With the open-sourced Java OpenJDK there 
> have been many, many new sources for Java installations that have become 
> available in addition to Oracle, IBM et.al., e.g. adoptOpenJdk.net, in all 
> versions, 8, 9, 10, 11, 12, 13, 14, with hotspot or with an alternative JVM, 
> etc. 
> 
> All these many and different Java packages adhere to update-alternatives, 
> making it possible to have all these versions installed in parallel. If I 
> need to test against a certain version of Oracle Java I just pick that from 
> update-alternatives, if I have a need for and adoptOpenJDK in a certain 
> configuration and version I just pick that. As a result of using 
> update-alternatives to set a default Java from the list of alternative Javas 
> installed, no matter from which session I start a BSF4ooRexx application it 
> will use exactly that default version of Java set with update-alternatives. 
> No need to fiddle around with any environment variables in any of these 
> sessions!
> 
> In the case of ooRexx supporting update-alternatives on Linux adds these 
> additional services and makes it easy on non-developers to maintain the 
> version of ooRexx to use by default (but also on developers who may have a 
> need to test their apps with different versions of ooRexx they know get used 
> at customer installations). 
> 
> If a Rexx application runs into a problem with a certain version of ooRexx 
> the user can install an older or a newer version of ooRexx to test whether 
> the Rexx application would work in that environment. If not switching back is 
> a breeze with update-alternatives, because no fiddling of the environment is 
> incurred on the user, no need to reboot or open a new session that the change 
> can take effect etc.
> 
> It also would allow e.g. Regina users to install ooRexx, switch termporarily 
> to it to test their Rexx programs and applications from this moment on with a 
> specific version of ooRexx and allows them to switch back to Regina. Or the 
> other way around.
> 
> So there are IMHO quite important features in update-alternatives for Linux 
> that Rexx users can benefit over time. Therefore if it is possible to support 
> it for ooRexx, please do so! 
> 
> Mark has offered his help to make sure that it works on ooRexx and with 
> Enrico‘s expertise on CMake (among other fields) it should be possible to 
> come up quickly with a stable, working, And tested version to the benefit of 
> the Rexx community as a whole!
> 
> —-rony
> 
> Rony G. Flatscher (mobil/e)
> 
>> Am 07.04.2020 um 08:33 schrieb P.O. Jonsson :
>> 
>> 
>>> Am 07.04.2020 um 01:40 schrieb Mark Hessling >> >:
>>> 
>>> The only "configuration" is when you want to switch between alternate Rexx 
>>> interpreters. Just as you have to run a script to switch 

Re: [Oorexx-devel] update-alternatives (Re: [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

[René Jansen]

it is great if it works but it is def old skool. This is the type of work 
(evaluating code against releases of whatever) that anyone I work with (yes, 
very young people, well compared to us) would do in a docker container.
I am a bit worried about the release schedule (what release schedule?) but I am 
ok with either fixing or postponing it, not really with spending a lot of time 
on it.

 With the documentation going well we should try to avoid breaking change and 
focus on showstoppers IMHO.

René.

> On 7 Apr 2020, at 13:11, Rony  wrote:
> 
> It may be true that one can individually change the ooRexx location and 
> version by changing PATH such that the operating system can find the desired 
> ooRexx in that particular session that changed the PATH to point to a 
> different ooRexx.. (This ability will not be lost if supporting 
> update-atlernatives on Linux, rather new possibilities of installation 
> combinations that do not break alternate installations becomes possible on 
> Linux.)
> 
> However, this is not matching what update-alternatives defines and allows for:



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] update-alternatives (Re: [Oorexx-svn] SF.net SVN: oorexx-code-0:[12051] main/trunk/platform/unix

[Rony]

It may be true that one can individually change the ooRexx location and version 
by changing PATH such that the operating system can find the desired ooRexx in 
that particular session that changed the PATH to point to a different ooRexx.. 
(This ability will not be lost if supporting update-atlernatives on Linux, 
rather new possibilities of installation combinations that do not break 
alternate installations becomes possible on Linux.)

However, this is not matching what update-alternatives defines and allows for:
- parallel installations of the same software in different versions,
- parallel installations of the equivalent software by different groups and 
vendors,
- listing of all of the alternative installations,
- making one of the alternatives the system default, such that no one has to 
fiddle with PATH settings in any session,
- maintaining the alternative packages.

This is not a service that developers of a certain package need like the ones 
on this list, rather it is a service for deploying and for the „customers“ of 
such packages that may be provided by different sources.

Personally, I have come to respect and admire this feature (as a huge time 
saver) on Linux regarding my work on BSF4ooRexx for which I need different 
versions of Java present in order to become able to test BSF4ooRexx on them. 
One reason being that BSF4ooRexx needs to work on Java 1.6/6 (current Java 
baseline) which is still deployed in companies, where the latest Java carries 
the version 14 since a few weeks! With the open-sourced Java OpenJDK there have 
been many, many new sources for Java installations that have become available 
in addition to Oracle, IBM et.al., e.g. adoptOpenJdk.net, in all versions, 8, 
9, 10, 11, 12, 13, 14, with hotspot or with an alternative JVM, etc. 

All these many and different Java packages adhere to update-alternatives, 
making it possible to have all these versions installed in parallel. If I need 
to test against a certain version of Oracle Java I just pick that from 
update-alternatives, if I have a need for and adoptOpenJDK in a certain 
configuration and version I just pick that. As a result of using 
update-alternatives to set a default Java from the list of alternative Javas 
installed, no matter from which session I start a BSF4ooRexx application it 
will use exactly that default version of Java set with update-alternatives. No 
need to fiddle around with any environment variables in any of these sessions!

In the case of ooRexx supporting update-alternatives on Linux adds these 
additional services and makes it easy on non-developers to maintain the version 
of ooRexx to use by default (but also on developers who may have a need to test 
their apps with different versions of ooRexx they know get used at customer 
installations). 

If a Rexx application runs into a problem with a certain version of ooRexx the 
user can install an older or a newer version of ooRexx to test whether the Rexx 
application would work in that environment. If not switching back is a breeze 
with update-alternatives, because no fiddling of the environment is incurred on 
the user, no need to reboot or open a new session that the change can take 
effect etc.

It also would allow e.g. Regina users to install ooRexx, switch termporarily to 
it to test their Rexx programs and applications from this moment on with a 
specific version of ooRexx and allows them to switch back to Regina. Or the 
other way around.

So there are IMHO quite important features in update-alternatives for Linux 
that Rexx users can benefit over time. Therefore if it is possible to support 
it for ooRexx, please do so! 

Mark has offered his help to make sure that it works on ooRexx and with 
Enrico‘s expertise on CMake (among other fields) it should be possible to come 
up quickly with a stable, working, And tested version to the benefit of the 
Rexx community as a whole!

—-rony

Rony G. Flatscher (mobil/e)

> Am 07.04.2020 um 08:33 schrieb P.O. Jonsson :
> 
> 
>>> Am 07.04.2020 um 01:40 schrieb Mark Hessling :
>>> 
>>> The only "configuration" is when you want to switch between alternate Rexx 
>>> interpreters. Just as you have to run a script to switch between different 
>>> versions of ooRexx.
>>> 
>>> With the relocatable executables that ooRexx has, how do man pages get 
>>> swapped?
>>> 
>> I just tried this out on my Mac with an installation to ~/Applications. man 
>> rexx works and give the expected information. I then removed 
>> ~/Applications/ooRexx5/bin from the path and man rexx stated that there was 
>> no information on rexx. I then copy and pasted the entire ooRexx 
>> Installation (a single icon on macOS) to /Applications (where ALL Apps 
>> reside), amended /Applications/ooRexx5/bin to the path and pop! man rexx 
>> give the information again, this time from another location.
>> 
>> My take on it is that at least on macOS there is no need to move the 
>> manpages to /usr/local/share/man or /usr/share/man, the OS