September 2015 - Installer-dev

Re: Problem with preflight script removing file
by Stephane Sudre 22 Sep '15

22 Sep '15

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(a)mac.com> wrote: > Some required reading: > https://derflounder.wordpress.com/2014/06/01/understanding-payload-free-pac… > > 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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/installer-dev/pepijn%40mac.com > > This email sent to pepijn(a)mac.com > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Installer-dev mailing list (Installer-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/installer-dev/howard%40antarestech.… > > This email sent to howard(a)antarestech.com > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Installer-dev mailing list (Installer-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/installer-dev/conor%40mac.com > > This email sent to conor(a)mac.com > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Installer-dev mailing list (Installer-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/installer-dev/conor%40mac.com > > This email sent to conor(a)mac.com > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Installer-dev mailing list (Installer-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/installer-dev/dev.iceberg%40gmail.c… > > This email sent to dev.iceberg(a)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(a)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(a)lists.apple.com

1 0

Re: Problem with preflight script removing file
by Howard Moon 21 Sep '15

21 Sep '15

> > Now... this all means that I need to modify my un-install script as well. Is there a way to close JUST that terminal window, after the user hits Enter or something? It's not vital, but it seemed annoying to me to leave that window open and have to close it or quit Terminal manually once the script was run. > Oh, I see it's a Terminal preference to close if the shell exists cleanly. I (and users) can just use that setting if it annoys. -Howard _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)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(a)lists.apple.com

1 0

Re: Problem with preflight script removing file
by Conor Schutzman 21 Sep '15

21 Sep '15

_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)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(a)lists.apple.com

1 0

Re: Problem with preflight script removing file
by Howard Moon 21 Sep '15

21 Sep '15

_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)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(a)lists.apple.com

1 0

Re: Problem with preflight script removing file
by Conor Schutzman 21 Sep '15

21 Sep '15

_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)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(a)lists.apple.com

1 0

Re: Problem with preflight script removing file
by Howard Moon 21 Sep '15

21 Sep '15

_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)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(a)lists.apple.com

1 0

Re: Problem with preflight script removing file
by Conor Schutzman 21 Sep '15

21 Sep '15

_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)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(a)lists.apple.com

1 0

Re: Problem with preflight script removing file
by Howard Moon 21 Sep '15

21 Sep '15

_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)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(a)lists.apple.com

1 0

Re: Problem with preflight script removing file
by Conor Schutzman 21 Sep '15

21 Sep '15

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(a)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(a)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(a)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(a)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(a)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(a)lists.apple.com) >>>> Help/Unsubscribe/Update your Subscription: >>>> https://lists.apple.com/mailman/options/installer-dev/pepijn%40mac.com >>>> >>>> This email sent to pepijn(a)mac.com >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Installer-dev mailing list (Installer-dev(a)lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/installer-dev/howard%40antarestech.… >> >> This email sent to howard(a)antarestech.com > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Installer-dev mailing list (Installer-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/installer-dev/conor%40mac.com > > This email sent to conor(a)mac.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)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(a)lists.apple.com

1 0

Re: Problem with preflight script removing file
by Howard Moon 21 Sep '15

21 Sep '15

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(a)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(a)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(a)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(a)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(a)lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/installer-dev/pepijn%40mac.com >>> >>> This email sent to pepijn(a)mac.com > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Installer-dev mailing list (Installer-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/installer-dev/howard%40antarestech.… > > This email sent to howard(a)antarestech.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)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(a)lists.apple.com

1 0