Can I sum this up as follows? There seems to be little (none :-( ) support for a system wide installation to /usr/local -> I will amend my (custom made) installers to install in /opt in the future
An installation to /opt would be an acceptable compromise? Since the "minimal Invasive" installations can not be automated I postpone work on that (with the exception of the USB version) The "Apple Centric“ installer will be in the hands of BSF4ooRexx also in the future For the /opt installation I can try to do the necessary for an automated (CMake - make - sudo make install - pkgbuild pkg installer with the following initial limitations: There will not be any symbolic links, at least not initially, hence the user will need to amend the path The installer will not launch the rxapi daemon, at least not initially Preflight and Postflight scripts will be added later -there will be no customized menus, at least not initially -the pkg will not have the ooRexx icon. I need to dive deeper in how to use pkgbuild for these things. A general question to the developers: When making the same type of build (release), is the names and the number of files created the same all the time or can it happen that in the course of development a new library (libhostemu.6.0.0.dylib) or executable (rxapi2) are added to the package? May sound like a strange question but when creating the preinstall and postinstall scripts I would not need to check this if the built package is static. At the moment I parse the manifest file to generate these scripts dynamically; this could be avoided if the number of files & the names are the same all the time. Hälsningar/Regards/Grüsse, P.O. Jonsson oor...@jonases.se > Am 17.09.2018 um 15:15 schrieb René Jansen <rvjan...@xs4all.nl>: > > I like the compromise suggested here - but of course there are limits to *nix > portability, and Mac is diverging (but being more secure, etc), as is Android. > > On the topic of the CMake install; I recently built an installer .rpm and > installed to another Linux distro; to my surprise the requirement for csh was > back again. I am almost certain we took that out some time ago, and wonder if > there has been a version management mishap. > > Someone remember? Or do I have to go through the logs? > > I am very interested in the USB installer, and will try to have a look at > that next. In any case, P.O., I hope you have the time to integrate that into > CmakeLists. > > best regards, > > René. >> On 17 Sep 2018, at 14:46, P.O. Jonsson <oor...@jonases.se >> <mailto:oor...@jonases.se>> wrote: >> >> Thank you Rony, this pretty much sums it up. Just to clarify one option >> below: >> >> There exists already a standalone ooRexx installation that I created for use >> on a USB stick, all that is needed is a USB stick (or any volume that can be >> mounted) with the name OOREXX5. Simply mount ooRexx 5.0.0 USB Build 11492 >> 2018-09-05.dmg from my Dropbox, drag everything over to the USB stick and >> change the path. Howto inside the image. No outstanding rights and no files >> residing on the target system after ejection. >> >> The USB version is a one-off that can be made at any time but not (yet) >> automated from CMake daily build. >> >> Hälsningar/Regards/Grüsse, >> P.O. Jonsson >> oor...@jonases.se <mailto:oor...@jonases.se> >> >> >> >>> Am 17.09.2018 um 14:11 schrieb Rony G. Flatscher <rony.flatsc...@wu.ac.at >>> <mailto:rony.flatsc...@wu.ac.at>>: >>> >>> Hmm, maybe we should first clarify that there are two possible >>> installations: >>> >>> system-wide (the current type of ooRexx installation on all systems) >>> pro: single installation for entire system, any user and any program can >>> use ooRexx >>> needs: sudo/priviledged installation and uninstallation >>> >>> user-confined (not yet available, but extremely important to be able to do) >>> pro: >>> installation can run on a stick as well >>> ooRexx can be used on otherwise locked systems where the user cannot >>> control what gets installed on his machine and what not >>> this would be extremely helpful for one owns ooRexx-tool-stick, but also >>> for showing off what ooRexx is capable of (thinking of my students who >>> could program Windows, MS Office, OpenOffice/LibreOffice, Java, .Net, >>> GUI-programming, etc.) >>> cons: >>> only the user is able to run ooRexx, no one else >>> if multiple users have user-confined installations, then currently ooRexx >>> will stumble over the single (system-wide) socket port it communicates >>> currently with rxapi, if another user has a (long) running ooRexx program >>> If a system-wide installation of ooRexx is sought, then it is sufficient to >>> link the binaries to /usr/local/bin, /usr/local/lib etc., no matter where >>> the ooRexx interpreter got installed to /opt, ~/Application or /usr/local. >>> In this case I would install the interpreter to /opt/ooRexx to not clutter >>> /usr/local and not make a system wide installation dependent on a >>> user-confined directory like ~/Application. >>> >>> In addition, IMHO: >>> A system wide installation should have scripts for relinking its binaries >>> to /usr/local in case something went wrong or different installers linked >>> to /usr/local, mistakingly replacing an already installed ooRexx version >>> (something like "link_to_usr_local.sh"). Also, an installation should have >>> an uninstall script ("uninstall.sh") that cleanly removes what its >>> installer created. >>> The location to install to on Unix-based systems should be the same on all >>> platforms to simplify (and to ease) managing the installation: for a >>> system-wide installation to /opt, for a user-confined installation to ~ (in >>> the MacOSX case maybe ~/Application). >>> ---rony >>> >>> >>> On 17.09.2018 11:19, René Jansen wrote: >>>> … to elaborate a bit further on that: >>>> >>>> I use the the cmake target option to install, as I build from source. I >>>> have to use that option anyway, because the way cmake (lists) is set up >>>> now, it uses a way to set the executable path that sets up ooRexx in the >>>> path that is used by brew (in my case: ~/homebrew/bin). I don’t like this >>>> because then there are managed programs and their dependencies (by brew) >>>> and unmanaged ones in the same directory; this is, in my opinion, not >>>> good. Of course, this would change if we got the install into brew and >>>> have it all managed. >>>> >>>> I would extend that point of view to the /Library/Frameworks variant; the >>>> fact that Apple installs language processors there, means to me that it is >>>> the place for Apple installed language processors. When I need a newer >>>> version, as I sometimes do, I check if brew has it and run from there; >>>> only when not available I build from source and move the executables to >>>> ~/Applications. >>>> >>>> So I am in favour of the ‘minimally invasive’ option as you call it, but >>>> then in ~/Applications and not in the home directory to indicate it is not >>>> package manager installed, and to group it with other language packages >>>> (for me, SWI Prolog is the most important one, but also Eclipse, NetBeans) >>>> that follow this convention. >>>> >>>> best regards, >>>> >>>> René. >>>> >>>> >>>>> On 17 Sep 2018, at 10:46, René Jansen <rvjan...@xs4all.nl> >>>>> <mailto:rvjan...@xs4all.nl> wrote: >>>>> >>>>> Hi P.O., >>>>> >>>>> I install in ~/Applications/ooRexx5.0.0/bin/rexx on nearly all my macs. I >>>>> found that several packages I use moved to this location, ~/Applications; >>>>> it plays well with the changing ‘system integrity’ policies and makes for >>>>> an easy uninstall. Also, I think one should not require Admin rights to >>>>> install a personal language tool in a personal directory on a machine; >>>>> neither should one force other persons on the same machine (if >>>>> applicable) to run the same release. >>>>> >>>>> I find myself running from Docker containers more and more nowadays, >>>>> where I just run the .rpm or .deb, but the native install on Apple goes >>>>> in ~/Applications. >>>>> >>>>> best regards, >>>>> >>>>> René. >>>>> >>>>>> On 16 Sep 2018, at 19:16, P.O. Jonsson <oor...@jonases.se> >>>>>> <mailto:oor...@jonases.se> wrote: >>>>>> >>>>>> What is the "right" place for installing ooRexx on a Mac? >>> >>> _______________________________________________ >>> Oorexx-devel mailing list >>> Oorexx-devel@lists.sourceforge.net >>> <mailto:Oorexx-devel@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> >> >> _______________________________________________ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> <mailto:Oorexx-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
