Re: Problem with preflight script removing file
Re: Problem with preflight script removing file
- Subject: Re: Problem with preflight script removing file
- From: Stephane Sudre <email@hidden>
- Date: Tue, 22 Sep 2015 17:02:31 +0200
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 <email@hidden> wrote:
> Some required reading:
> https://derflounder.wordpress.com/2014/06/01/understanding-payload-free-packages/
>
> 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 <email@hidden> 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 <email@hidden> 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 <email@hidden> 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 <email@hidden> 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 <email@hidden> 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 (email@hidden)
> 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 <email@hidden> 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 (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Installer-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Installer-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Installer-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Installer-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
--
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden