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 <rony.flatsc...@wu.ac.at> 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
