September 2009 - Installer-dev

Re:Re: downgrade .pkg fail on Snow Leopard
by searockcliff 21 Sep '09

21 Sep '09

site_archiver(a)lists.apple.com Delivered-To: Installer-dev(a)lists.apple.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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: downgrade .pkg fail on Snow Leopard
by Greg Neagle 21 Sep '09

21 Sep '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

downgrade .pkg fail on Snow Leopard
by searockcliff 21 Sep '09

21 Sep '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.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: 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 the installer log file saved anywhere?
by Kevin Brock 18 Sep '09

18 Sep '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Ah, thank you very much. I was looking for a log file with my package name, or something derived from it, so I hadn't spotted it. Kevin _______________________________________________ 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.… Ben Staveley-Taylor wrote: So my next question is how to rename that file to something less generic that won't get overwritten or appended to by the next installer that the user runs. Is there a plist setting for the installer log name? Can I rename it in my postflight script? (The installer goes on writing to it after postflight exists, so that sounds a bit dodgy...) This is basically a system log file, so you don't want to rename it or remove it. If you want to save a copy, then save a copy... Have a script do 'cp /var/log/install.log <wherever you want to put it>' It does roll over when it hits 1MB, so you definitely want to save it off if you need to refer to it later. This email sent to site_archiver(a)lists.apple.com

1 0

Re: postflight-preflight on snow -leopard
by karan rath 18 Sep '09

18 Sep '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=2PpN2L2ymwrE3btThrnyKyDHThjqT73Ubea7Bsp3Xs0=; b=Iovt989HimyHYoXuH/QRMIbW3XVO/TbfkQrlp9FPpFMZ0CYmnKwzldCDQ9l9NeUBmU R2rkFikHwE8TTiU6JZKmKOqdIplUETL0eWPACaC3RqUNUzWjuivo4BETqEYOMz+Qw/qe 18e6CxD6rvMOy3c5d6lCWHwKdVajW9LqCUuWo= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QclgP5WqRK+rqHDSIlWDAblC+mjUtV6WyT7ovhZga6zZ1ezBKKxf/bShVQ46wEMhgi ug/8mpIhvoHrjwnn0qko61UGhcPOPcX7GJXPErcunqZXSqErgj4xZdRImaHh+kDpNsHz aWE2gSyab5PCwhEZUuxQNUc9mkbsOwabyXPH0= _______________________________________________ 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

installer failing under a chroot environment
by justin blecher 18 Sep '09

18 Sep '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=A5fuJ7brez6GAucnJsSG4lOxvOTGUfVh7cYAS72Leww=; b=pl1Nxvu0r/gOiAVRG6krWRDbylgH8tRqCjnbq2Tev0Gpjq81ipZLKhyb/YarJyDmP/ qEX1KhAYrBhs2PEbQESXtcj49uBFn5pLfZwlV1vrKolhGsiioYuE1d8ue5UvlKLiF+AL 3MIPQYUQazaOGYs//WdT6o444nVB0EwCtZ42E= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YADr9vroffMiuuYUyh3FXD2ub5414X/rsONF0zh6Ctam4c9E4hvX/+/3KNzlvxhHdE +d8OA/kFLgz15lnemAkrDGK+YvVqtXegNHErvzLeB+UJ8kzE5kwQPSyDtll8QUb5Qv9a Oes0o4/k0Tv22olFdc8mOEQEAcUG3U2i7t22c= hello again everyone, i posted the following message over on the InstaDMG list, but got no response. maybe someone here can shed some light? short summary: it seems to be an installer problem (i'm on 10.5.8). installer is failing under a chroot environment... sometimes. i'm guessing running installer chrooted is probably not 'supported', but the way in which it fails is really interesting. lastly, i apologize for it containing a lot of InstaDMG terminology -- if you can get past that, you'll see the fun installer stuff. -- i'm running into an issue where installer is crapping out when run under the chrooted environment of InstaDMG. it's failing on certain packages, and i can't figure out what's causing it to fail vs. succeed. the same packages fail each run. here's a partial transcript of the debug log: http://pastie.org/private/zip9ovjez8hbaogpq3sheq the first 600 lines show things progressing normally. then it starts failing. (note that i passed -t /Volumes/data2/tmp as the PACKAGE_DMG_MOUNT_LOCATION since the host boot volume only has <15GB free.) for those of you who don't want read the pastie, let me summarize: installer is failing with a generic obj-c exception: installer: Error verifying PACKAGE_NAME package contents: *** -[NSCFString substringFromIndex:]: Range or index out of bounds (where PACKAGE_NAME is the package it's attempting to install) it doesn't seem to matter whether the package i'm attempting to install is a mpkg or a regular pkg (flat or directory). the installer binary is definitely giving the error (i ran strings on it and found that printf string). my search on google for '"error verifying" "package contents" installer' yield nothing useful. one mention on the afp548 forums re: the MS Office 12.1.0 updater yielding a package verification error, but that is a JavaScript error, not an obj-c error. i can't find any information about what constitutes "package verification" by installer. i've tried messing around with the various .plist files, but intentionally creating malformed XML doesn't seem to cause problems for installer. (i haven't tried the .dist files yet, though.) here's what else i've done w/r/t debugging so far: - i reduced the # of pkgs to just the ones that were causing problems, removing all OS updates (mainly so it would go faster). in other words, the InstaDMG is just using the cached 10.5.0 image and then moving on to the CustomPKGs folder. as i said, the same pkgs fail each time. some pkgs are downloaded and some are custom-rolled. - i attempted to run the chroot install on another [previously imaged] volume i had mounted. interestingly, that worked just fine. note that volume had been booted and used, and it did not originate from an InstaDMG workflow. - i dumped the environment vars in the instadmg script at the point of the chrooted install. nothing interesting here. - i removed the 'trap' statement and ctrl-c'd InstaDMG after it failed installing the first few pkgs, allowing me to retain the environment that InstaDMG is working in (the mounted system image with the shadow file). i then ran the chroot'd install and interestingly enough, it failed with the same error. (hooray for replicating behavior!) note: i'll eventually mount the image manually and not kill InstaDMG in the middle of its script -- commenting out the line was faster for me right now while i'm tracing the code. - installer seems to have other problems besides installing when executed within the chrooted environment -- it seems to have problems getting -pkginfo, too, failing with the same error. this is driving me nuts. any ideas or pointers? thanks, -justin _______________________________________________ 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

postflight-preflight on snow -leopard
by Pooja Hemanth 18 Sep '09

18 Sep '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: Aco4b3VXUiDLn3qpReu3mfcHStwVWQAAwjBQ Thread-topic: postflight-preflight on snow -leopard Hi All, I was trying to run few of the applications and observed in the install log that the postflight scripts don't run on snow leopard.Is any one else experiencing this ? is there a solution ? Am I looking at some wrong log ? Thanks, Pooja -----Original Message----- From: installer-dev-bounces+adampeck=smarttech.com(a)lists.apple.com [mailto:installer-dev-bounces+adampeck=smarttech.com@lists.apple.com] On Behalf Of justin blecher Sent: Friday, September 18, 2009 8:51 AM To: Iceberg-Dev Cc: installer-dev(a)lists.apple.com Subject: Re: clarification re: Mac OS X standard directories inside a component's hierarchy wow, thanks for taking the time to explain all of this -- i really appreciate it. sorry for it taking me forever to thank you. (this installer stuff is not my primary job, so i don't get to spend all that much time on it.) see below for my comments... On Thu, Aug 27, 2009 at 6:38 PM, Iceberg-Dev<dev.iceberg(a)gmail.com> wrote: > > On Aug 27, 2009, at 12:52 AM, justin blecher wrote: > >> On Wed, Aug 26, 2009 at 4:28 PM, Iceberg-Dev<dev.iceberg(a)gmail.com> wrote: >>> >>> On Aug 26, 2009, at 9:45 PM, justin blecher wrote: >> >> [...] >>>> >>>> * is my assumption/interpretaton -- anytime there are items that >>>> belong in a "standard directory", a separate package must be made for >>>> them, targeted to that standard directory -- correct? >>>> >>>> * are my evaluations and suggestions for the fixing (hah!) the >>>> offending packages on the right track? (not like i'm interested in >>>> fixing them, i'm just trying to grok the concepts for my own >>>> packages.) >>> >>> IMHO, this warning is just plain bullsh*t. >> >> ooookay. care to elaborate why you feel that way? :) > > Sure: > > o This would imply that you have almost to create one package for each > component you want to install. Obviously if you just need to install one > .app application in /Applications and you don't need to have it > distributable through Apple Remote Desktop, you don't need an installer. But > if you need to install an application, a kernel extension, a launchd script, > some documentations, etc., you would end up with a lot of components when > it's not needed. ok, this is where Apple's docs really confused me. their hypothetical "Levon.app" project separated the files into separate components and never really fully explained both sides of the story. btw, it seems like MS Office 2008 did follow this approach -- they separated their packages out into dozens of individual packages for each component, each targeted at a different directory (very organized, albeit a bit overwhelming). as an aside, the original 12.0.0 installer strangely left no receipts, but the SP1 and SP2 updates left a whole boatload. anyone know under what circumstances that happens? > o Not all the standard directories are created by default depending on the > version of the OS you are using. For instance, /Library/StartupItems was not > created by a clean install until Mac OS X 10.X X>=3. Other examples can be > found easily. I have 2 in mind but I can't talk about it before tomorrow > even though it's the 28th here. > > So let's say you need to install something into /Library/THISFOLDER where > THISFOLDER is a standard directory created in version 2 of the OS but not in > version 1 and you need to support both 1 and 2. I tend to believe the > installer will fail to install on version 1 of the OS if you specify the > default location to be /Library/THISFOLDER and if it works, then where is it > going to find the correct permissions it needs to apply to this standard > directory? excellent point. thanks for elucidating that. > o There is a minor bug related to custom folder icons when you set the > default location to be a standard directory instead of /. hmph. this doesn't concern me immediately. i suppose i'll google it if it bites me. > o Apple does not follow this guideline and I'm not referring to the OS. The > Apple Remote Desktop installation package does not follow this guideline. > And the guys working on Apple Remote Desktop probably know a few things > about installation. > > When in Rome, do as the Romans do, not as the Visitor Center recommends you > to do. interesting. i suppose i'll have to investigate apple's own installers a bit more closely. [...] > The problem is that you can't forecast if the correct permissions are not > going to change. > > For instance: > > - /Library/Widgets > > Mac OS X 10.4: ./Library/Widgets 40775 0/80 > > Mac OS X 10.5: ./Library/Widgets 40755 0/0 > > - /Library/StartupItems > > Mac OS X 10.1: root:admin was fine > > Mac OS X 10.4: root:wheel was mandatory > > Therefore if you are going to overwrite the permissions for a standard > directory, use the permissions for the most recent release of the OS. > > Ideally, you should not have too. Installer.app should be clever enough to > fix them when you install something inside them. good point. at the moment, i don't have to worry about supporting multiple OS versions, as i'm just creating packages for InstaDMG, and deploying only one OS version. i'll definitely keep this in mind, though. thanks again for explaining all of this stuff to a n00b. -justin _______________________________________________ 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/adampeck%40smarttech.c… This email sent to adampeck(a)smarttech.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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: clarification re: Mac OS X standard directories inside a component’s hierarchy
by justin blecher 18 Sep '09

18 Sep '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aZK752+MQK2KwSvf/8v8xO4MCeE+sbKEfFMs/l+dLVQ=; b=TWvzoOA6tcDyBxMu3qtsLYW38REDSAM0nDme2nV0Rl5yolUzzAoaRnYika2+U7y6Fn dQS+Q2Rt5XIqgV9FOjMlXZhcnOIh0rv5/DyWfLcvJHVFwTdGGMTH+XqckwDlP+6YY9q9 e49hhoZTZbK+GwWg7qekyLJg85l7Y/YnMj5mM= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cWOJH78qvzwvpN6VbNp6lx36vDTCkcvHZpMwXQg0tOF1/jFD5Q/btZTKhgs+2jyQnb B0LqTb5JtI3u6C6D6uFZ1+ZS5dmvUnIntvbJuttOa/3rmG8ueyry7xihEZFvwTE2VbVq 5zJGccHxnb3iaFQzHjYa5v0d9eeTPCu2szgCs= wow, thanks for taking the time to explain all of this -- i really appreciate it. sorry for it taking me forever to thank you. (this installer stuff is not my primary job, so i don't get to spend all that much time on it.) see below for my comments... On Thu, Aug 27, 2009 at 6:38 PM, Iceberg-Dev<dev.iceberg(a)gmail.com> wrote: > > On Aug 27, 2009, at 12:52 AM, justin blecher wrote: > >> On Wed, Aug 26, 2009 at 4:28 PM, Iceberg-Dev<dev.iceberg(a)gmail.com> wrote: >>> >>> On Aug 26, 2009, at 9:45 PM, justin blecher wrote: >> >> [...] >>>> >>>> * is my assumption/interpretaton -- anytime there are items that >>>> belong in a "standard directory", a separate package must be made for >>>> them, targeted to that standard directory -- correct? >>>> >>>> * are my evaluations and suggestions for the fixing (hah!) the >>>> offending packages on the right track? (not like i'm interested in >>>> fixing them, i'm just trying to grok the concepts for my own >>>> packages.) >>> >>> IMHO, this warning is just plain bullsh*t. >> >> ooookay. care to elaborate why you feel that way? :) > > Sure: > > o This would imply that you have almost to create one package for each > component you want to install. Obviously if you just need to install one > .app application in /Applications and you don't need to have it > distributable through Apple Remote Desktop, you don't need an installer. But > if you need to install an application, a kernel extension, a launchd script, > some documentations, etc., you would end up with a lot of components when > it's not needed. ok, this is where Apple's docs really confused me. their hypothetical "Levon.app" project separated the files into separate components and never really fully explained both sides of the story. btw, it seems like MS Office 2008 did follow this approach -- they separated their packages out into dozens of individual packages for each component, each targeted at a different directory (very organized, albeit a bit overwhelming). as an aside, the original 12.0.0 installer strangely left no receipts, but the SP1 and SP2 updates left a whole boatload. anyone know under what circumstances that happens? > o Not all the standard directories are created by default depending on the > version of the OS you are using. For instance, /Library/StartupItems was not > created by a clean install until Mac OS X 10.X X>=3. Other examples can be > found easily. I have 2 in mind but I can't talk about it before tomorrow > even though it's the 28th here. > > So let's say you need to install something into /Library/THISFOLDER where > THISFOLDER is a standard directory created in version 2 of the OS but not in > version 1 and you need to support both 1 and 2. I tend to believe the > installer will fail to install on version 1 of the OS if you specify the > default location to be /Library/THISFOLDER and if it works, then where is it > going to find the correct permissions it needs to apply to this standard > directory? excellent point. thanks for elucidating that. > o There is a minor bug related to custom folder icons when you set the > default location to be a standard directory instead of /. hmph. this doesn't concern me immediately. i suppose i'll google it if it bites me. > o Apple does not follow this guideline and I'm not referring to the OS. The > Apple Remote Desktop installation package does not follow this guideline. > And the guys working on Apple Remote Desktop probably know a few things > about installation. > > When in Rome, do as the Romans do, not as the Visitor Center recommends you > to do. interesting. i suppose i'll have to investigate apple's own installers a bit more closely. [...] > The problem is that you can't forecast if the correct permissions are not > going to change. > > For instance: > > - /Library/Widgets > > Mac OS X 10.4: ./Library/Widgets 40775 0/80 > > Mac OS X 10.5: ./Library/Widgets 40755 0/0 > > - /Library/StartupItems > > Mac OS X 10.1: root:admin was fine > > Mac OS X 10.4: root:wheel was mandatory > > Therefore if you are going to overwrite the permissions for a standard > directory, use the permissions for the most recent release of the OS. > > Ideally, you should not have too. Installer.app should be clever enough to > fix them when you install something inside them. good point. at the moment, i don't have to worry about supporting multiple OS versions, as i'm just creating packages for InstaDMG, and deploying only one OS version. i'll definitely keep this in mind, though. thanks again for explaining all of this stuff to a n00b. -justin _______________________________________________ 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 the installer log file saved anywhere?
by Ben Staveley-Taylor 18 Sep '09

18 Sep '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Organization: Oracle Thread-index: Aco4R1UE3REQEAMcRHKC08y/vOTwDAAFL1QQAAQ5ROA= Ah, thank you very much. I was looking for a log file with my package name, or something derived from it, so I hadn't spotted it. So my next question is how to rename that file to something less generic that won't get overwritten or appended to by the next installer that the user runs. Is there a plist setting for the installer log name? Can I rename it in my postflight script? (The installer goes on writing to it after postflight exists, so that sounds a bit dodgy...) Thanks, Ben Staveley-Taylor Oracle -----Original Message----- From: Glover,David [mailto:David.Glover@prometheanworld.com] Sent: Fri 18 September 2009 13:35 To: ben.staveley-taylor(a)oracle.com; installer-dev(a)lists.apple.com Subject: RE: Is the installer log file saved anywhere? /private/var/log/install.log (this is opened in Console). Or open Console, click Show Log List, expand LOG FILES and then /var/log and install.log is there too. _______________________________________________ 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 the installer log file saved anywhere?
by Glover,David 18 Sep '09

18 Sep '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: Aco4R1UE3REQEAMcRHKC08y/vOTwDAAFL1QQ Thread-topic: Is the installer log file saved anywhere? /private/var/log/install.log (this is opened in Console). Or open Console, click Show Log List, expand LOG FILES and then /var/log and install.log is there too. -----Original Message----- From: installer-dev-bounces+david.glover=prometheanworld.com(a)lists.apple.com [mailto:installer-dev-bounces+david.glover=prometheanworld.com@lists.app le.com] On Behalf Of Ben Staveley-Taylor Sent: 18 September 2009 11:04 To: installer-dev(a)lists.apple.com Subject: Is the installer log file saved anywhere? Is the installer log automatically saved anywhere? If not, is there a common way that people do this? It seems like a pretty standard thing to want to do with an installer. I put quite a bit of diagnostic info in the log in case things go wrong on unanticipated system configurations. I would like to be able to tell customers to send in their log file. I've looked in /Library/Receipts, /Library/Logs, ~/Library/Logs and /var/log which seems to contain some Apple logs. There are some installation logs to be found, but not mine. I know the user can save the log manually before they quit the installer, but be honest, no user is going to do that proactively and they may well have deleted the installer and be unable to re-run it later on to get the diagnostics. Thanks for any info, Ben Staveley-Taylor Oracle _______________________________________________ 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/david.glover%40prom etheanworld.com This email sent to david.glover(a)prometheanworld.com Promethean Limited is a company registered in England and Wales with company number 1308938 and VAT number GB 572 2599 18 ______________________________________________ Promethean Ltd and or associated and or subsidiary companies : The views expressed in this communication may not necessarily be the views held by Promethean Ltd and or associated and or subsidiary companies. This e-mail is for the exclusive use of the addressee(s). Unauthorised disclosure, copying or distribution is prohibited. This e-mail message has been swept for the presence of computer viruses. Promethean Ltd and or associated and or subsidiary companies accepts no liability for any loss resulting from this email transmission. Promethean, Promethean House, Lower Philips Road, Blackburn, Lancashire, BB1 5TH, UK. Please update your records accordingly. Thank you! _______________________________________________ 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