May 2005 - Installer-dev - lists.apple.com

Re: Is setting a custom folder icon possible?
by Christopher Ryan 18 May '05

18 May '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com You shouldn't have to depend on dev tools to do this. Hi Chris, Am 18.05.2005 um 05:37 schrieb Christopher Ryan: Mike, I would consider it a bug. Mike -- Mike Fischer Softwareentwicklung, EDV-Beratung Schulung, Vertrieb Web: <http://homepage.mac.com/mike_fischer/index.html> Note: I read this list in digest mode! Send me a private copy for faster responses. _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… A lot of things changed in the Installer between 10.3.9 and 10.4, so if it worked before and does not work now, then it is an even more serious bug (regression). Chris This shouldn't be necessary and is either 1) a missing feature in the installer or 2) a bug. Glad you see it that way and I agree. The interesting thing is that on my 10.3.9 system the custom icon flag is set correctly while on the 10.4 and 10.4.1 systems my friend used it wasn't. I'll try to get this verified and report a formal bug if I can verify this. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Is setting a custom folder icon possible?
by Mike Fischer 18 May '05

18 May '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Am 18.05.2005 um 8:07 schrieb St?phane Sudre <ssudre2(a)wanadoo.fr>: Radar# 3635123 Custom icon folder not saved/set/installed 27-Apr-2004 10:33 AM Thanks, I'll mention that in my bug report. Mike -- Mike Fischer Softwareentwicklung, EDV-Beratung Schulung, Vertrieb Web: <http://homepage.mac.com/mike_fischer/index.html> Note: I read this list in digest mode! Send me a private copy for faster responses. _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… IMHO, this is more a limitation of the pax format. That sounds plausible. But why does it work correctly on my 10.3.9 system? Maybe the installer has something like the workaround I have in mind already implemented? (Set the flag for every installed folder containing an Icon\n file.) This email sent to site_archiver(a)lists.apple.com

1 0

Re: "postflight" shell script and $2 variable + Search methods
by John Kirkham 18 May '05

18 May '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com John On 18-May-05, at 9:03, Joe Ridge wrote: On May 18, 2005, at 12:57 AM, Mark Douma wrote: /Applications/Utilities/foo/foo.app Thanks in advance, Mark Douma This email sent to ridge(a)umiacs.umd.edu _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… The key "IFPkgReceiptLocation" seems to be only on OS versions up to and including 10.3. On 10.4 it seems to have been replaced by "IFPkgRelocatedPath" which is likely a better name for it, though it does break backwards compatibility if you have scripts that rely on it. When you install a package in leaves a receipt package in /Library/Receipts. In this the receipt package the Info.plist has been modified to include the installation destination under the key IFPkgReceiptLocation. You should ba able to find a way to use this info for your update package. I'm having trouble with running a postflight shell script successfully after the installation of a package that uses a few search methods to locate the application bundle that's being updated. Here's an example situation that I'm dealing with: Let's say the application's name is "foo.app", and it's stored within a "foo" folder. The default location for the install is /Applications/, although it's relocatable and can be installed anywhere on the root volume. A person runs the installer and chooses to install the package into the /Applications/Utilities/ folder. The final path of the installed application then, is: During this install, a "postflight" script is run. This script needs to know the path to the "foo.app" application bundle where the user chose to install it. Using "$2/foo/foo.app" works great. $2 is resolved to wherever the user chose to install it. I now have a newer package version that needs to be installed. This package is meant for someone who already has a prior version of the application installed in the location of their choosing. What I would like to be able to do, if possible, is to have this package set up so that it's not relocatable, but so that it searches for and locates the existing installation wherever it might be. Since I need to choose a default location for the package, I choose the /Applications/ folder as in the original package. I choose the "foo.app" bundle and define 3 search rules for it: 1) CheckPath search method which looks at "/Applications/foo/foo.app" 2) CheckPath search method which looks at "/Applications/Utilities/foo/foo.app" 3) LaunchServicesLookup search method that should find the application if it's not found in either of the first two locations. As with the original package, I need to run a "postflight" script at the end of the installation. Again, the script needs to know the path to where the application bundle is that's been updated. As before, I'm attempting to use "$2/foo/foo.app" to refer to the application. This time, however, it's not working properly (or, at least it's not doing what I would like). I was assuming that, in this case, the $2 variable would be for the resolved installation path that was determined as a result of the search methods used above. Instead, it seems like only the default location for the install, the /Applications/ folder, is the path that's passed into the script as the value for $2. So, if the user had chosen to install the original package anywhere other than /Applications/, the "postflight" shell script will fail (which causes a problem and makes the overall installation a failure -- even if the install succeeds, if this script fails, the application won't be set up correctly). Is this the expected behavior, or any idea what I'm doing wrong? Is it possible to do what I'd like to do? I'm on OS X 10.4.1, using Iceberg 1.1.4 to create the package, and testing the package on 10.4.1. ---------------------------------------------------------------------- ----- Mark Douma Grand Rapids, MI, USA mdouma46(a)mac.com http://homepage.mac.com/mdouma46/ ---------------------------------------------------------------------- ----- _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/ ridge%40umiacs.umd.edu _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/ jkirkham%40alias.com This email sent to jkirkham(a)alias.com This email sent to site_archiver(a)lists.apple.com

1 0

postflight script not creating alias with Tiger
by Ken Hawkins 18 May '05

18 May '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com APP_DIR="Applications/PromoStudio" APP_NAME="PromoStudio.app" # weird thing but we have to touch the .app before we can create an # alias touch "$LINK_FROM" and in my log file this is spat out: thanks, ken; _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… in my postflight script that is run i have the followign bit of scripting: ### # note about creating the alias ... # the strange syntax is necessary because of differences between os10.1, 10.2, and 10.3 # 10.3 doesn't return a full colon-seperated path for a user's file, instead it just starts # with the user's name, which will not work for creating the alias. LINK_FROM="$3$APP_DIR/$APP_NAME" echo "Our linkable app is $LINK_FROM" >> $LOG_FILE colonfrom=`osascript -e "tell application \"Finder\" to set p1 to (POSIX FILE \"$LINK_FROM\") as file"` colonto=`osascript -e "tell application \"Finder\" to set p1 to (POSIX FILE \"/Users\") as file"` colonto=$colonto"$USER:Desktop:" echo "Creating alias (from: $colonfrom, to: $colonto)" >> $LOG_FILE osascript -e "tell application \"Finder\" to make new alias at \"$colonto\" to file \"$colonfrom\"" Our linkable app is /Applications/PromoStudio/PromoStudio.app Creating alias (from: file Macintosh HD:Applications:PromoStudio:PromoStudio.app:, to: file Macintosh HD:Users:ken:Desktop:) with 10.3 this worked fine and dandy however with tiger this does not create anything on the desktop at all so i have a couple of questions. is this happening to anyone else? is there a new(better) way to create aliases on a users desktop? and finally, where does the osascript log to? This email sent to site_archiver(a)lists.apple.com

1 0

Re: "postflight" shell script and $2 variable + Search methods
by Joe Ridge 18 May '05

18 May '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On May 18, 2005, at 12:57 AM, Mark Douma wrote: /Applications/Utilities/foo/foo.app Thanks in advance, Mark Douma This email sent to ridge(a)umiacs.umd.edu _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… When you install a package in leaves a receipt package in /Library/ Receipts. In this the receipt package the Info.plist has been modified to include the installation destination under the key IFPkgReceiptLocation. You should ba able to find a way to use this info for your update package. I'm having trouble with running a postflight shell script successfully after the installation of a package that uses a few search methods to locate the application bundle that's being updated. Here's an example situation that I'm dealing with: Let's say the application's name is "foo.app", and it's stored within a "foo" folder. The default location for the install is / Applications/, although it's relocatable and can be installed anywhere on the root volume. A person runs the installer and chooses to install the package into the /Applications/Utilities/ folder. The final path of the installed application then, is: During this install, a "postflight" script is run. This script needs to know the path to the "foo.app" application bundle where the user chose to install it. Using "$2/foo/foo.app" works great. $2 is resolved to wherever the user chose to install it. I now have a newer package version that needs to be installed. This package is meant for someone who already has a prior version of the application installed in the location of their choosing. What I would like to be able to do, if possible, is to have this package set up so that it's not relocatable, but so that it searches for and locates the existing installation wherever it might be. Since I need to choose a default location for the package, I choose the / Applications/ folder as in the original package. I choose the "foo.app" bundle and define 3 search rules for it: 1) CheckPath search method which looks at "/Applications/foo/foo.app" 2) CheckPath search method which looks at "/Applications/Utilities/ foo/foo.app" 3) LaunchServicesLookup search method that should find the application if it's not found in either of the first two locations. As with the original package, I need to run a "postflight" script at the end of the installation. Again, the script needs to know the path to where the application bundle is that's been updated. As before, I'm attempting to use "$2/foo/foo.app" to refer to the application. This time, however, it's not working properly (or, at least it's not doing what I would like). I was assuming that, in this case, the $2 variable would be for the resolved installation path that was determined as a result of the search methods used above. Instead, it seems like only the default location for the install, the /Applications/ folder, is the path that's passed into the script as the value for $2. So, if the user had chosen to install the original package anywhere other than /Applications/, the "postflight" shell script will fail (which causes a problem and makes the overall installation a failure -- even if the install succeeds, if this script fails, the application won't be set up correctly). Is this the expected behavior, or any idea what I'm doing wrong? Is it possible to do what I'd like to do? I'm on OS X 10.4.1, using Iceberg 1.1.4 to create the package, and testing the package on 10.4.1. ---------------------------------------------------------------------- ----- Mark Douma Grand Rapids, MI, USA mdouma46(a)mac.com http://homepage.mac.com/mdouma46/ ---------------------------------------------------------------------- ----- _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/ridge% 40umiacs.umd.edu This email sent to site_archiver(a)lists.apple.com

1 0

Re: Is setting a custom folder icon possible?
by Mike Fischer 18 May '05

18 May '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Hi Chris, Am 18.05.2005 um 05:37 schrieb Christopher Ryan: Mike, Mike -- Mike Fischer Softwareentwicklung, EDV-Beratung Schulung, Vertrieb Web: <http://homepage.mac.com/mike_fischer/index.html> Note: I read this list in digest mode! Send me a private copy for faster responses. _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This shouldn't be necessary and is either 1) a missing feature in the installer or 2) a bug. I would consider it a bug. Glad you see it that way and I agree. The interesting thing is that on my 10.3.9 system the custom icon flag is set correctly while on the 10.4 and 10.4.1 systems my friend used it wasn't. I'll try to get this verified and report a formal bug if I can verify this. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Is setting a custom folder icon possible?
by Mike Fischer 18 May '05

18 May '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Hi Stéohane, Am 18.05.2005 um 08:08 schrieb Stéphane Sudre: On mardi, mai 17, 2005, at 03:13 PM, Mike Fischer wrote: OK, thanks. Then I do: "$1/Contents/Resources/SetCustomIcon" -C "$2/$folderName" to set the custom icon using the included tool. Again thanks for your help! Mike -- Mike Fischer Softwareentwicklung, EDV-Beratung Schulung, Vertrieb Web: <http://homepage.mac.com/mike_fischer/index.html> Note: I read this list in digest mode! Send me a private copy for faster responses. _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… So to summarize, I understand that: - There is no intrinsic method to set Finder flags on installed files or folders in an installer package; - Using a postflight script it is possible to trigger an executable that sets Finder flags; - Since no executable, capable of setting Finder flags, exists on a standard install of Mac OS X, a suitable executable must be provided in the installer package. Correct? At least, that's what I would do. I've got a rough workaround based on your idea in place. I need to test and fine-tune a bit but that is not big problem. I added some shell code to make the postflight script independent of the install location and somewhat independent on the foldername. The former is done by evaluating the parameters to the script and the later by using lsbom to extract the name of the folder like this: folderName=`lsbom -d -p f "$1/Contents/Archive.bom" | grep "/ProductName"` This relies on the assumption that the folder will be named something like "<ProductName> x.y" for example. I'm probably going to change this to a more general method by making the tool set the custom icon flag for any folder in the specified hierarchy that contains an Icon\n file. This email sent to site_archiver(a)lists.apple.com

1 0

Re: "postflight" shell script and $2 variable + Search methods
by Alexey Proskuryakov 18 May '05

18 May '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com User-agent: Microsoft-Entourage/11.1.0.040913 On 18.05.2005 08:57, "Mark Douma" <mdouma46(a)mac.com> wrote: > As with the original package, I need to run a "postflight" script at > the end of the installation. Again, the script needs to know the path > to where the application bundle is that's been updated. ... > Is this the expected behavior, or any idea what I'm doing wrong? Is > it possible to do what I'd like to do? My enchancement request for this (rdar://3916392) is still Open/Analyze, so I presume it isn't possible. You may also want to consider <http://lists.apple.com/archives/installer-dev/2004/Dec/msg00009.html> and <http://lists.apple.com/archives/installer-dev/2004/Dec/msg00007.html> (the latter is fixed in 10.4). - WBR, Alexey Proskuryakov _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Is setting a custom folder icon possible?
by Stéphane Sudre 18 May '05

18 May '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On mardi, mai 17, 2005, at 08:37 PM, Christopher Ryan wrote: Mike, IMHO, this is more a limitation of the pax format. _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This shouldn't be necessary and is either 1) a missing feature in the installer or 2) a bug. I would consider it a bug. Radar# 3635123 Custom icon folder not saved/set/installed 27-Apr-2004 10:33 AM This email sent to site_archiver(a)lists.apple.com

1 0

"postflight" shell script and $2 variable + Search methods
by Mark Douma 18 May '05

18 May '05

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com /Applications/Utilities/foo/foo.app Thanks in advance, Mark Douma _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… I'm having trouble with running a postflight shell script successfully after the installation of a package that uses a few search methods to locate the application bundle that's being updated. Here's an example situation that I'm dealing with: Let's say the application's name is "foo.app", and it's stored within a "foo" folder. The default location for the install is / Applications/, although it's relocatable and can be installed anywhere on the root volume. A person runs the installer and chooses to install the package into the /Applications/Utilities/ folder. The final path of the installed application then, is: During this install, a "postflight" script is run. This script needs to know the path to the "foo.app" application bundle where the user chose to install it. Using "$2/foo/foo.app" works great. $2 is resolved to wherever the user chose to install it. I now have a newer package version that needs to be installed. This package is meant for someone who already has a prior version of the application installed in the location of their choosing. What I would like to be able to do, if possible, is to have this package set up so that it's not relocatable, but so that it searches for and locates the existing installation wherever it might be. Since I need to choose a default location for the package, I choose the / Applications/ folder as in the original package. I choose the "foo.app" bundle and define 3 search rules for it: 1) CheckPath search method which looks at "/Applications/foo/foo.app" 2) CheckPath search method which looks at "/Applications/Utilities/ foo/foo.app" 3) LaunchServicesLookup search method that should find the application if it's not found in either of the first two locations. As with the original package, I need to run a "postflight" script at the end of the installation. Again, the script needs to know the path to where the application bundle is that's been updated. As before, I'm attempting to use "$2/foo/foo.app" to refer to the application. This time, however, it's not working properly (or, at least it's not doing what I would like). I was assuming that, in this case, the $2 variable would be for the resolved installation path that was determined as a result of the search methods used above. Instead, it seems like only the default location for the install, the / Applications/ folder, is the path that's passed into the script as the value for $2. So, if the user had chosen to install the original package anywhere other than /Applications/, the "postflight" shell script will fail (which causes a problem and makes the overall installation a failure -- even if the install succeeds, if this script fails, the application won't be set up correctly). Is this the expected behavior, or any idea what I'm doing wrong? Is it possible to do what I'd like to do? I'm on OS X 10.4.1, using Iceberg 1.1.4 to create the package, and testing the package on 10.4.1. ------------------------------------------------------------------------ --- Mark Douma Grand Rapids, MI, USA mdouma46(a)mac.com http://homepage.mac.com/mdouma46/ ------------------------------------------------------------------------ --- This email sent to site_archiver(a)lists.apple.com

1 0