I’m afraid the App Store or a simple DMG is pretty much it. I get the impression they want to encourage developers to have an App be the one do whatever is required say on first launch (not always possible for a plug-in). This way the App can ask for the correct permissions and be properly sandboxed, unlike a package which can run pretty much any arbitrary code it wants. When you think about sandboxing, system integrity protection, gatekeeper, etc. it seems to be the way they are going. However I just checked the iTunes installer and that’s still a pkg so as already said it’s probably not going to be dropped anytime soon, it may never be dropped but I certainly get the feeling that they want to move away from it.
Packages seems to update regularly enough for me. Not had any issues in Sierra or high Sierra.
It seems my installer for both Win and Mac doesn’t overwrite older plugin files sometimes.
I can’t reproduce this myself, but have received some issue reports.
I use packages for Mac, Inno setup for Win.
Has anyone run into the same problem?
In your Inno Setup script, you can add
Flag: ignoreversion to your Source entries.
On Mac, there’s no equivalent flag that I’ve found, but I will say that the package installer framework itself is VERY sensitive to version numbers and dates. Get those right and you should be ok.
Thank you, I will check that flag in Inno setup.
On Mac, packages has pre/post script slots.
So I guess it could be possible to add script that deletes older files before installing newer one.
But I have’t figured out how to write those script yet.
A script that I use from within Packages to remove the previous version. Because the user can choose which plugin format to install, each one has his own script. Here’s an example for AAX:
# Author: Samuel Gaehwiler
# This script is used by the installer package.
# Without this, the plugin files will keep their original creation (and even
# modification) date when updated. This can lead to strange host behaviour
# (For example the Pro Tools AAE error -7106).
if [ -e "$folder" ]
rm -R "$folder"
Also, keep in mind that Packages has this setting shown in the image below, which you should probably check for all the binaries you want to install (plug-ins and apps)
Thanks for clarification on where to install. I was thinking you needed to install to both system and user folders after going through the Mac section of this tutorial:
@anthony-nicholls Thanks for the tip about this - I swear it used to be fairly user friendly, but I was totally stuck working with Packages today. I could not set the Payload destination I wanted.
This tip you suggested of using
New Folder works, it’s just a tedious way to set a filepath! Say I’m setting the AAX plug-in directory as my destination (
/Library/Application Support/Avid/Audio/Plug-Ins). I can see
Library/Application Support in the file hierarchy (since it’s a “Standard Folder”) – but then I have to use
New Folder 3 times in a row, drilling down each successive level after that, and each time typing in the directory name… instead of, say, just being able to select the final destination in a standard file dialog!
Am I overlooking some other, simpler way to set a destination? Using
Add Files... without first drilling down to the desired destination doesn’t work… the destination is always set as the last directory you had selected, with no way to change it later.
I would suggest learning
productbuild, which Packages is really more or less a glorified wrapper for. This repo is a good resource to plunder (I helped develop the installer script there).
You could make a folder on disk called
Avid with everything you want in it and add this instead (once you’ve selected the folder just click Add). However…
- I’m not sure if this will remove everything else in Avid when installed rather than merge it
- The advantage of adding each folder is you can see in the UI what permissions are going to be set for each folder - any accidental change of permissions on disk won’t impact the result.
As said above you could also use
productbuild maybe even use
packages just to get your initial distribution xml. You can take apart any distribution package by running
pkgutil --expand </path/to/pkg/to/expand> </path/to/a/new/folder/that/will/contain/the/contents>. This is really useful for seeing exactly what packages does or others have done in a distribution xml. Much easier than reading the documentation
I’ve used both methods they have there pro and cons.
One thing I would say though is that Apple have for a long time been pushing away from pkg installers and encouraging other methods. Unfortunately for plugins there’s not an immediately obvious alternative but if you’re able to make a simple dmg where users drag and drop what they want then I would probably recommend something like that nowadays. One issue will be of course what happens when the AAX Plug-Ins folder doesn’t exist.
OK, thanks for the pointers about using
productbuild. For future-proofing and ultimate control, that is the road I’ll need to take I guess.
And, as @crandall1 showed earlier in this thread, the AAX signing step can be handled by the same script, which is one less step to handle manually (just gotta make sure that I’ve got my iLok on hand when building installers, which isn’t always the case).