Another possible solution (that would need to be tested though) is to use a distribution: - create a distribution project - make sure the distribution will be built flat (Project > Settings > Format > Flat) - add/set an uninstall package that will have no payload but will include your pre-install cleanup script - add the original package - make sure in the Presentation > Installation Type step to: . select "User sees Standard Install only" . have the uninstall choice before the original choice in the Package Name list . set the uninstall choice state to be "Required". On Mon, Sep 21, 2015 at 9:12 PM, Conor Schutzman <conor@mac.com> wrote:

Some required reading: https://derflounder.wordpress.com/2014/06/01/understanding-payload-free-pack...

Also, if you have time, check out Greg Neagle’s presentations at some of the recent conferences. Sadly, I don’t think his workshop at PSU2015 was videoed, but the slide notes should at least be around.

What I would do… • Build an uninstall script that removes the receipt and any files in question. Set that script as the Pre-Installation action on the Scripts tab of Packages. • Drag the package you actually want to install into the “Additional Resources” section of the Scripts tab of Packages. • Write an install script, set that script as the Post-Installation action on the Scripts tab of Packages (see below). • Build the package.

Example installation script:

#!/usr/bin/env bash resourceLocation=$(dirname "$0") packageName=‘yourSpiffyPackage.pkg' if [[ -e “${resourceLocation}/${packageName}" ]]; then installer -dumplog -verbose -pkg “$resourceLocation/$packageName" -target "$3" -allowUntrusted >> “/private/tmp/something.txt else exit 1 fi exit 0

On Sep 21, 2015, at 11:29 AM, Howard Moon <howard@antarestech.com> wrote:

Hi Conor,

Thanks for the help! It looks like "open" is the way to go. I'm not that familiar with Unix scripts, and wasn't aware of how to "open" a file as if double-clicking on it in Finder.

So, in order to put everything into just one file (so as not to confuse users), it looks like a payload-less package is the way to go. I've got that working except the post-flight script to run the installer itself... where does that get located on the user's drive, so that I can issue the "open" command on it?

(Alternatively, can I just add the plug-in component's .pkg file as a resource to my distribution package, and run just THAT from a post-install script? I am trying that now, but I keep getting an error and I'm guessing it has to do with the location of that .pkg file resource.)

Thanks, Howard

On Sep 21, 2015, at 9:50 AM, Conor Schutzman <conor@mac.com> wrote:

As you've noticed, a pre-install script to remove the receipt won't occur in time for the component to be installed.

If you want the graphical installer to launch, you need to call it, or a document for it, with an open command, rather than with the "installer" command.

A possible solution may be a payload less package. Add the package you want to install to the resources folder. Then uninstall (and remove the receipt) in preinstall, and call installer with your package in post install. This is counter intuitive, as you are wrapping a package in a package, but it often the simplest solution to deploy a vendor package without modifying it.

If however you have control over the component package you are trying to upgrade, you may be able to side step this whole thing simply by changing the package identifier to something different than you used last time. This is why many vendors put the version number of the software directly in the package identifier.

On Sep 21, 2015, at 9:39 AM, Howard Moon <howard@antarestech.com> wrote:

I even tried running a separate script that deletes the old bundle and then runs the package, but the "installer" command in Terminal does not allow the .pkg to show its user interface (at least as far as I can tell), which I need it to do, as if launched from Finder. Grrr....

-Howard

On Sep 21, 2015, at 9:14 AM, Howard Moon <howard@antarestech.com> wrote:

Hi Pepijn,

yes, I tried adding that. But the problem seems to be that the decision to skip the plug-in component occurs BEFORE the pre-install script is run. (I had said "pre-flight" previously, but in Packages, it is called "pre-install".) So no matter what my script does, the installer has already decided it will not install my plug-in. Is there any way to get around this, other than to run an uninstaller separately before running the new installer?

Thanks, Howard

On Sep 21, 2015, at 7:49 AM, Pepijn Bruienne <pepijn@mac.com> wrote:

Howard, if you're manually removing files you probably also need to make sure the installer DB has no record of it. Have you tried a pkgutil --forget <your pkg id> in the preflight?

Thanks, Pepijn.

-- Pepijn Bruienne Sent with Airmail

On September 21, 2015 at 10:47:40 AM, Howard Moon (howard@antarestech.com) wrote:

The installer.log file says this:

Sep 21 07:27:27 Howards-MacBook-Pro.local installd[467]: PackageKit: Skipping component "com.antares.Mic Mod EFX.aaxplugin" (2.0.2-2.0.2-*-*) because the version 4.0.0-4.0.0-*-* is already installed at /Library/Application Support/Avid/Audio/Plug-Ins/Antares Audio Technologies/Mic Mod EFX.aaxplugin.

This had previously WORKED on MY system, but no longer. Now I am getting the same behavior as my testers reported, which is that the new file is not installed. (Which is a good thing, since it’s hard to diagnose a problem one cannot replicate!) Apparently, the pre-install script is not running prior to the installer software detecting that the new version has an older version number, so even though the script runs and removes the plug-in, the installer skips it because it cannot update to an older version.

How can I resolve this?

Thanks, Howard

On Sep 21, 2015, at 7:12 AM, Howard Moon <howard@antarestech.com> wrote:

Hi,

One of our installers is removing the old bundle (via a pre-flight script), but failing to install the new bundle. We need help resolving the situation.

We have a Packages-built installer (.pkg) which includes a pre-flight script to remove a particular audio plug-in bundle before continuing to install the new one. This was done because certain installations of the old bundle had version numbers that were incorrect - higher than the new bundle’s version number - and so are not replaced automatically. For our VST3 bundles, this is working correctly, but for our AAX bundles, something in the system seems to be holding onto the deleted bundle, preventing writing of the new one. After the installer runs, the old bundle is gone, but the new one has not been written. The user has to run the installer a *second* time in order to get it ti install the new bundle. Obviously, that is not a good result.

Is there some reason for this behavior? Perhaps ownership of the containing folder hierarchy or something? More importantly, is there some way to ensure that this does not happen?

The script line to remove the bundle is simple enough. Here it is. Is there something that I can do to modify the script to make the system let go of the old bundle and allow the new one to write?

rm -fR /Library/Application\ Support/Avid/Audio/Plug-Ins/Antares\ Audio\ Technologies/Mic\ Mod\ EFX.aaxplugin rm -fR /Library/Application\ Support/Avid/Audio/Plug-Ins/Mic\ Mod\ EFX.aaxplugin

(That second line is just in case the plug-in was moved to the root of Plug-Ins folder, which we have seen happen.)

Any thoughts?

Thanks, Howard

_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/pepijn%40mac.com

This email sent to pepijn@mac.com

_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/howard%40antarestech.c...

This email sent to howard@antarestech.com

_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/conor%40mac.com

This email sent to conor@mac.com

_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/conor%40mac.com

This email sent to conor@mac.com

_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/dev.iceberg%40gmail.co...

This email sent to dev.iceberg@gmail.com

-- Packaging Resources - http://s.sudre.free.fr/Packaging.html _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com