I want to create MAC installer and would like to know which type of installer suitable for my requirements?
My Requirements are
I have bash script which does following operation
Get Hardware ID and some details specific to the hardware
Construct XML
Generate PLIST
Download an DMG file from internet (Using curl)
Mount DMG
Launch .app inside the DMG.
Can you please suggest me whether I can go the DMG or use PackageMaker to create .PKG file?
Thanks
Bala
I am not aware of anyways to trigger a script on mounting a DMG. But here you have a solution by creating a PKG with pre-install/post install scripts.
Your bash script can be added as pre-install or post-install script of the PKG. It doesn't really matter whether you are adding it as pre/post install scripts, since your PKG is just going to execute the scripts and not doing any file copy etc.
If needed you can embed the PKG in a DMG, so that it becomes a mount disk. Also DMG can show the license files if needed.
Related
How to change the MSIX installation path??
Referred this url - "https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes"
Always installer package is created in default location "C:\Program Files\WindowsApps"
Need to set the installer location to different location.
The installation path of an MSIX package cannot be changed. All the files you have included in your package are installed inside an app-specific folder under "C:\Program Files\WindowsApps<your app>\".
This is a design decision from Microsoft. Only for MSI/EXE installers you can change the install path.
If you want to add files in other folders too, you need to copy them the first time your application is launched. For that, you have multiple options. You can write your own code inside your application to copy the files in other folders or you can use tools like Advanced Installer to do it for you.
To understand more about MSIX and how files outside of the installation path can be managed I recommend this article/presentation I wrote last month.
I have cloned and built the waf script using:
./waf-light configure
Then to build my project (provided by Gomspace) I need to add waf and the eclipse.py to my path. So far I haven't found better than this setenv script:
WAFROOT=~/git/waf/
export PYTHONPATH=$WAFROOT/waflib/extras/:$PYTHONPATH
export PATH=~/git/waf/:$PATH
Called with:
source setenv
This is somehow a pretty ugly solution. Is there a more elegant way to install waf?
You don't install waf. The command you found correctly builds waf: /waf-light configure build Then for each project you create, you put the built waf script into that projects root directory. I can't find a reference, but this is the way in which waf:s primary author Thomas Nagy wants the tool to be used. Projects that repackage waf to make the tool installable aren't "officially sanctioned."
There are advantages and disadvantages with non-installation:
Disadvantages:
You have to add the semi-binary 100kb large waf file to your repository.
Because the file contains binary code, people can have legal objections to distributing it.
Advantages:
It doesn't matter if new versions of waf break the old API.
Users don't need to install waf before compiling the project -- having Python on the system is enough.
Fedora (at least Fedora 22) has a yum package for waf, so you could see that it's possible to do a system install of waf, albeit with a hack.
After you run something like python3 ./waf-light configure build, you'll get a file called waf that's actually a Python script with some binary data at the end. If you put it into /usr/bin and run it as non-root, you'll get an error because it fails to create a directory in /usr/bin. If you run it as root, you'll get the new directory and /usr/bin/waf runs normally.
Here's the trick that I learned from examining the find_lib() function in the waf Python script.
Copy the waf to /usr/bin/waf
As root, run /usr/bin/waf. Notice that it creates a directory. You'll see something like /usr/bin/.waf-2.0.19-b2f63c807a4215294bf6005410c74c18
mv that directory to /usr/lib, dropping the . in the directory name, e.g. mv /usr/bin/.waf-2.0.19-b2f63c807a4215294bf6005410c74c18 /usr/lib/waf-2.0.19-b2f63c807a4215294bf6005410c74c18
If you want to use waf with Python3, repeat Steps 2-3 running the Python script /usr/bin/waf under Python3. Under Python3, the directory names will start with .waf3-/waf3- instead instead of .waf-/waf-.
(Optional) Remove the binary data at the end of /usr/bin/waf.
Now, non-root should be able to just use /usr/bin/waf.
That said, here's something to consider, like what another answer said: I believe waf's author intended waf to be embedded in projects so that each project can use its own version of waf without fear that a project will fail to build when there are newer versions of waf. Thus, the one-global-version use case seems to be not officially supported.
I am working on a project that is transitioning from CMake to Bazel. One critical feature that we are apparently losing in the bargain is the ability to install the project, so that it can be used by other (not necessarily Bazel) projects.
AFAICT, there is currently no built in support for installing a project?!
I need to create a portable (must work on at least Linux and MacOS) way to install the project. Specifically:
I need to be able to specify libraries, headers, executables, and other files (e.g. LICENSE) that need to be installed.
The user needs to be able to specify an absolute prefix where things should be installed.
I really, really should be able to execute the "install" step more than once, giving different prefixes each time, without Bazel getting confused (i.e. it must not try to "remember" what files it already installed, or if it does, must understand when the prefix is different from last time).
Libraries should be installed to the right place (e.g. lib64), or at least it should be possible for the user to specify the correct libdir.
The install step MUST NOT touch the time stamp on any file from a previous install that has not changed. (Ideally, Bazel itself would handle this; using the install command is tricky and has potential portability issues. Note platform requirements, above.)
What is the best way to go about doing this?
Unless you want to do specific package (e.g. deb or rpm), you probably want to create an executable rule that does the install for you.
You can create a rule that would create an executable (e.g. a shell script) that does the install for you (e.g. do checksums to check if there are change to the installed file and does the actual copy of the files if they have changed). You would have to use the extension language to do, that would look similar to what the docker rules does to load an image with the incremental loader
Addition: I forgot to say that the install itself would be run by using the run command: bazel run install if the rule is named install in the top level BUILD file.
We want to include RabbitMQ in our product, which further requires Erlang OTP. We don't want our customers to install Erlang before they install our product and want to find out ways to include Erlang in our own product installer.
What are some strategies to do this? We want to support Windows & Linux. At the moment my understanding is that there is no ZIP version of Erlang on Windows. So here's what i am thinking
Include Erlang OTP installer and kick it off when our product installer runs
Install Erlang OTP, zip the install dir and have our product installer unzip it on the customer's machine
. . . ?
Thanks for any advise.
Edited on 10/21
I figured it out. When erl.exe start it spins up a name resolver daemon process (epmd.exe) for distributed erlang. The location of this exe is hard coded in /otp/install/path/bin/erl.ini.
After copying the otp installation from C:\Program Files to a directory of my choosing, I had to update the erl.ini file to reflect the change in the path to the empd process. After that I uninstalled OTP from c:\Program Files and was able to start erlang from the directory where it was copied over.
Ranjit
Another option which is standard way for releases is using rebar. This bundles OTP and it is more cleaner approach than copying the installed windows binaries and change the erl.ini or change the erl script in linux.
I have a machine which doesn't give me local admin rights. Is it still possible to run erlang on it, as I cannot run a windows .exe installer to install erlang?
You can copy erl.exe (plus the runtime system and all the libraries you need) from another installation and run it without the need to install. As long as you are allowed to execute files it should be okay.
Forgive me for not being as smart as Zubair,
but I would like to know exactly how to do this.
I do not have admin privilege, cannot run installers, and cannot copy files to C:\WINDOWS.
In particular, I cannot write to C:\WINDOWS\WinSxS or C:\WINDOWS\system32.
How do I get a list of exactly what libraries are required by the various erlang executables ?
I have all the MS redistributable libraries and manifests,
but I don't know where to put them to make it work.
The redistributable library structure has directories such as
Microsoft.VC90.ATL, Microsoft.VC90.CRT, etc. Each directory contains relevant dlls and a manifest.
Do I copy all the contents into the ERL_HOME\bin directory or ERL_HOME\erts-x.y.z\bin or ERL_HOME\erts-x.y.z\lib ?
or leave them in some other directory and put those entries in the PATH ?
or do I need to build the paths implied by the manifests (i.e. where they would be copied into the WinSxS cache) using hashes and version numbers in the paths, then put those entries in the PATH ?