I need to build a installer for my application which has below components/tasks -
Main .app file
Helper .app file
Supporting folders
.plist file which needs to be copied to /Library/LaunchAgents
load the plist file using "launchctl load"
As we see from the above components,
1. files needs to be extracted to /Applications/ABC
2. Execute a perl command file as administrator
As step2 above involved admin activities, installer should prompt admin/local username and password. Based on this, we need to proceed with next steps.
Can someone please suggest -
1. Installer tool (Preferably FREE) for the above scenario
2. Installer should prompt login/pwd while executing command file
You can use pkgbuild and productbuild commands to build the installer. Check this very detailed answer here
The official documentation for these commands are here pkgbuild and productbuild
There is another pkg creating app available: iceberg
Related
I am building an installer using InstallForge.
Along with my install, i need to run some Third Party installers, for example, Cuda 9.1.
What I want is to create an installer, and a folder structure like this:
Installer.exe
InstallsDir
-Cuda.exe
-ThirdpartyInstall.exe
Then when my installer runs, it should also run the other two exe files.
In the setup process for InstallForge, it allows you to run commands, which i can use to run the exe files.
There is a command variable: <installpath>\ that is used to run a file from the path that my programme is installed to.
My question is, is there a similar command that i can use to run a file in the directory that the installer runs from?
How can i set a relative link to the current directory using InstallForge setup?
I want to throw error dialog (and fail the installation) if certain file exists on the system. Is it possible?
pkg = flat file pkg
It's possible to customize the installer in various ways to get whatever functionality is needed generally. Typically in your scenario either a Pre-Installation script could be used or a Package Installer Plugin. The options would normally be defined in the installer package's distribution.dist which essentially functions as the schema it will follow.
See productbuild in the man pages:
--scripts scripts-path
- The contents of scripts-path is added to the product archive for use by system.run() commands commands in the distribution. This is valid only for product archives targeted to the OS X Installer application.
--plugins plugins-path
- The contents of plugins-path is added to the product archive for use by the OS X Installer application's plugin mechanism. It will normally contain a InstallerSections.plist file, and one or more plugin bundles.
↳ About Distribution Definition Files & productbuild
I am working to automate the process of releasing a Mac application using xCode 5. The app is only distributed outside of the Mac App Store (Direct Distribution). I know that I can add a Run Script to be executed during the Build Phase to automate the process. I am currently using a ruby script from Craig Williams for appcast automation. The script is here: https://github.com/CraigWilliams/appcastautomation/blob/SnowLeopard/appcast_automation.rb
My question is: Are the Validate and Distribute steps necessary? Provided that code signing is completed, can I simply run the automation script and use the .zip file produced by the script or must I go through the steps outlined below and then process the "Exported" app using the script?
My current process is as follows:
Select "Archive" from xCode's Product menu.
Open Organizer and press "Validate" button.
Press "Distribute" and choose "Export Developer ID-signed
Application" then press "Next".
Select my Developer ID code signing certificate.
Press "Export" to save the MyApp.app file.
Once I have the "Exported" .app file, I am manually running the script via Terminal to create the .zip file required for Sparkle appcast. I am hoping to skip the xCode export process as a first step towards automated distribution.
Yes, it is possible to completely automate an app release process without needing to go through Xcode's Organizer to "Validate" and "Distribute" an application for Direct Distribution. It requires several Run Script Build Phases to be added to the target in XCode. This is what I ended up doing...
1) The first step was to code sign all frameworks AND the application bundle so that when the appcast automation script runs, the app that gets zipped is already code signed. This omits the need to export the app via Organizer. This Run Script is added immediately after all "copy" build phases.
IDENTITY="Developer ID Application: My Great Company."
FRAMEWORK_LOC="${BUILT_PRODUCTS_DIR}"/"${FRAMEWORKS_FOLDER_PATH}"
codesign --verbose --force --sign "$IDENTITY" "$FRAMEWORK_LOC/Growl.framework/Versions/A"
codesign --verbose --force --sign "$IDENTITY" "$FRAMEWORK_LOC/Sparkle.framework/Versions/A"
codesign --verbose --force --sign "$IDENTITY" "$BUILT_PRODUCTS_DIR/$FULL_PRODUCT_NAME"
2) The 2nd Run Script executes a Ruby script that creates a .zip file of the app and an .xml file for appcast distribution via Sparkle. The original script came from here: https://github.com/CraigWilliams/appcastautomation/blob/SnowLeopard/appcast_automation.rb
I have customized the script to also copy the unzipped app to another folder that is later used to automagically create a .dmg file.
The 2nd run script is simply:
script_file="appcast_automation.rb"
$SRCROOT/$PRODUCT_NAME/${script_file}
3) The 3rd Run Script creates a .dmg file with a custom icon, background, version, license agreement, etc... I use DropDMG's command-line tool (http://c-command.com/dropdmg/) to create the .dmg file. I have added the wm_license and wm_layout directories into the Xcode project so the script has access to them and they are versioned using git.
This Run Script is set to "Run script only when installing".
VERSIONNUM=$(/usr/libexec/PlistBuddy -c "Print CFBundleShortVersionString" "${PROJECT_DIR}/${INFOPLIST_FILE}")
layout_folder="${PROJECT_DIR}/${PROJECT_NAME}/wm_layout"
license_folder="${PROJECT_DIR}/${PROJECT_NAME}/wm_license"
dmg_folder="/Users/username/Desktop/WindowMizer/${PROJECT_NAME}_$VERSIONNUM/${PROJECT_NAME}"
dropdmg --custom-icon --license-folder=$license_folder --layout-folder=$layout_folder $dmg_folder
The list of Run Scripts and the automation files in Xcode looks like this:
So, by simply choosing "Archive" in Xcode, I end up with: a .zip file and .xml files for automatic updates via Sparkle and a .dmg file for first-time (new) downloads. The end result is this...
Everything is code-signed and ready to deploy. The only thing left to do is to upload the files to the server, which could be automated, but I prefer to do that part manually.
When time permits, and if I am allowed, I will post my modified copy of appcast_automation.rb in a github repository and add a link to it from here.
Hope this helps someone else!
For one of my projects i used building script using packagemaker. Packagemaker allows specify all files i need install from root, so my root had following structure:
Applications
My Application.app
Library
Preferences
MyCompanyName
some.xml
another.xml
tmp
default.p12
usr
local
bin
sometool
I.e. it had following features:
Some configuration files preinstalled for all users, to global Preferences (some.xml, another.xml)
Some command line tool being used as by main app as user in /usr/local/bin
Program uses certificates and there is one default certificate which will be moved to right place in postflight
How to do same with productbuild? Possible?
The basic tool that does the packaging you want is pkgbuild, not productbuild. pkgbuild will let you specify a root directory that, upon installation, will be expanded to '/'. So, you can use that for all of what you discuss in your question (though an installer putting something in /tmp is a bit weird - I'd suggest baking the cert right into your postinstall script).
I am trying to create a Mac Installer to streamline the process for my end users.
The idea is that they could just run one installer that would take them through the process of installing 5 different pieces of software.
Another complicating factor is that I would like to run different types of installers within this one meta-installer in a particular order
1) Install a bunch of files (including the DMG files)
2) Run one DMG file and install it
3) Run another DMG file and install it
4) Run a .sh python script that would execute through the terminal
5) Install some more files
My questions are:
Is this possible?
Any idea how to do this with either Iceberg or Package Maker?
Thanks in advance!
Well, it is definitely possible.
Seems like your requirement is that you have 5 different installers and you want to install them one by one from a single main installer.
In this case, lets assume you have all these installers inside a dmg file with one main installer (All those installers can be hidden so that user sees only the main installer when he mounts the dmg).
Now, inside the postinstall script of this main installer (assuming you use packagemaker), you can write the logic to get the current path and start installing your sub-installers. You will have to do some error-handling as well to know if any of the installation failed.
What I provided is a high level idea of how to achieve what you want to do. I am sure there are a lot of improvements you can think of when you are writing the main postinstall file that contains all the business logic.
Command to install a packagemaker installer from the script:
installer -pkg "path_to_pkg" -target /
See man page of installer for more options.