October 2010 - Installer-dev

Re: Installing to /Users/<username>/...
by Karl Kuehn 31 Oct '10

31 Oct '10

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:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=I8i1PJnN4DX/A3nhk3+nqeeeLdHB3CWG1n6hEHX8XXg=; b=gETm8Cuwi58TwPMQu2MrAN7QtHXtJCkyKC/VCshHzoImQR8HlqjFlJT/myFTbY/XOj mT1uwrYoG4Ql93Et7uVDY8AshZYUQO3gA2tRcH1YG6zxk6+vVFHtmPPb+0btuPzeRlBM 2nii9jEbK7+NfhmvtoK8dqbvQbWACf28wLlOE= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=UDg0zUwZyTTQU7LRVsRl4kfhHY4gr5EaQsy4XjrI3U2leReSU1jnmVUZfW62Zz5hR2 fG7+l3ryTlR0kK/7QPLWyigI4IVQ7U9piIgSB4d+cj0RPt30PPY4PTi1DLpbLcBXKeMs ZgVjBynwlcBK9VxG3gF5TcFmSVIgn6/kM/9+k= On Oct 31, 2010, at 9:08 AM, eveningnick eveningnick wrote: > The problem with my app is that it needs to install some other files, except that plist. Installer, besides creating .plist, copies some "template" documents to the user folder (more specifically, to /Users/<username>/Library/Application Support/MyAppName/...) and provides uninstaller as well (an Applescript bundle). None of this changes where your application should be stored: - If you have user-specific application support files, then those should be copied into place when the user either first launches or, better yet, first needs those files. This should never be a part of the installer, since there could be multiple users on the system, some of whom have yet to be created. As an example think about a school computer lab where hundreds of people may log in with their own home directory on any one of hundreds of computers. If your program can work elegantly in that situation then you probably have done things the right way. - My second point here is that you should at least re-think the idea of template documents. Is this something that the majority of your users are actually going to customize? Could you just keep using the template documents onboard your app (in Contents/Resources), and then offer a button to copy this out for only the users that need them? Again the example to think about is the school lab, and here the poster child for doing it wrong is MS Office. In order to launch MS Word the Office Setup Assistant needs to create the user database, a 20-30 MiB file. The fast majority of this file is to support Outlook/Entourage, and the only thing that Excel and Word use from it are a few personal details. So for labs that don't use Outlook/Exchange they are still creating 20-30 MiB files per user and storing them on a server. Do you really need to follow this example? Or could you better use individual preferences to override the settings you want to offer? - So if you have managed to drop the weight of all of the stuff that you were going to copy into place, then you have probably eliminated the need for any sort of uninstaller, also dropping that need (and the need to put a folder into */Applications). So now you are back to an app that is naturally drag-and-drop. My general feeling is that unless you are installing something like a kext, or components that are shared by multiple, separately downloaded, applications, needing an installer is real evidence of need to re-think how the application works. > I want to create installer, because the presence of an installer is a sign for a user that application "does something more that just runs when the bundle is double clicked". And if i provide only an application bundle, the user will feel tempted to just move it to trash when he doesn't need my application. You are making the mistake that people will remember how things installed, and make this differentiation that you find. In my experience neither is the case. > This plist file, that is supposed to launch my app everytime the system starts, will cause problems (because, user had qlreqdy moved bundle to trash, Launchd can't find app's executable - it'll pop up that annoying message every 10 seconds). These template documents, that i install to /Users/<Username>/Library/Application Support/MyAppName... will take some of the disc space like a garbage that otherwise would have been cleaned by uninstaller, etc I don't know what your app actually does, but why are you using Launchd to do this? And why do you need the app crash protection turned on? For GUI apps (and I presume that is the case here) a launch item is a better solution, and provides something that the user can turn on and off themselves. Plus it only will annoy them once on login if things are broken. And if you absolutely need to use a LaunchAgent setup to do this, you can create ~/Library/LaunchAgents and put your files in there. It will only apply to that single user, and all the files can be properly non-admin modifiable. And beyond what I wrote above about the template files... are your files really that big that leaving behind some per-user customization is going to be anything other than a rounding error when we are looking at the disk? If so, then I think you have to re-think things (ala the MS Office example from above). > I just want to make it obvious and intuitive for a user, that he should uninstall the app the same way he installed it - using an installer or uninstaller. > > That's why i need an Installer (just like Microsoft Office does). I am aware of that it is not recommended to install a decent application in any other way than copying a bundle. I think you are making two mistakes here: 1) holding out MS Office as an example of something that does it right (they have come a long way, but are still working at it). 2) I think you have missed that (at least before Office 11) you can drag-and-drop MS Office, and it will then take care of user setup when first run (doing more than it should...). > I am considering also a possibility to install all the files not to user home directory, but to /Library/Application Support/MyApp... and /Library/Launch Agents/MyApp/... , but: my application needs to manage that plist file (it should be possible for it to create that file, modify it or delete it). Unfortunately, the system doesn't let me to do that - an application doesn't have enough of privileges. Maybe if i solved this problem, i wouldnt have needed that $user variable from a script. Although i have no idea how to modify a file in /Library/LaunchAgents/... from an "ordinary user" application. > Can it be done somehow? Can it be done? Yes. But I think I have made my case that it should not be done. -- Karl Kuehn larkost(a)softhome.net _______________________________________________ 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: Installing to /Users/<username>/...
by Nick Peelman 31 Oct '10

31 Oct '10

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:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=y5E2CJKDjJBulsOo/ke67/cLpOpv5doq6RCaDKiLiSk=; b=Tb14q/Elb45sMEAM/kLkxmYk9k8YstC9pW1w5karu/HXQEOZ70CzQqWemYEGiJbu5A Y9on7P95O01OOklG3cJeDnPzojQOq1Yjy01veO5xy+AdPvCRSHaNrMvNmYXn0ONYWjmj Emx/cr9p7RY5M/JZuEL9kj4+SqrmXOJk3dHrI= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=CQeQ7DtHnW94GsXMUJ133alO02uoEfdB+uh7tQeOOVZ7FR392FSLEzyqypm8OprfCI ritO4L5kItEXcjLu3QBAJzZBbWKERcHOcW5A9BOjn+UYlAIdJPy9WMP0X9wgCb2UA7t3 jhnxQmQzCh5bhP6kCL7sYYevwYWK/feiGX3vg= _______________________________________________ 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 smime.p7s

1 0

Re: Installing to /Users/<username>/...
by eveningnick eveningnick 31 Oct '10

31 Oct '10

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:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=47Aweb0qxSv4WdMSqJ1nbrkdWX3dbXtx+LnzHiNU/jY=; b=Z3RgELrqD0O4zqtccYupZRoZQoZwadplNi5vWPaMvR0+foI1NRX1FGiInrUlEmfyAG j4nEweY3XObFleI7yYS5Uj18+MfgtmFPMd2ZAkmT/OR057uGTRmcRXfYVPg4CxDF6Das cIzLBNbaeKmZdZv798zqSI5JAPBCZe1s1lZKI= 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 :content-type; b=tdUH9Qt1pI1+yetAQ217nuhLqzY0Ci4X6ERdfOSgcNvOCL94ozoq48e7yZA0CWUnAo e+QpI/l+QO7pjGUGyurxu0Bl4I1D6xUbxgZkk4OnYrduDGmgLO/N32i9m/eDweWqSdyC 2HzR8NcYy0P8jJ/Vp3IJK6xOvJXJF8qVSuvK0= _______________________________________________ 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

Installing to /Users/<username>/...
by eveningnick eveningnick 31 Oct '10

31 Oct '10

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:received:date:message-id :subject:from:to:content-type; bh=4cOOurZyajU7GaA8WpkpwW1bhc5AdjPVt2/yWrqOows=; b=pIiI5FF4HLsMNWcFGvz5QdI/JCJwCGcdUByIjtB+/aYZjupOVGYxvkmfhy0L+O2Nmg x1hxMEQIg9gAIDRGaEaKvD0FtkMLWe/J0qi0XCi5blLj1RVjkIXOy1FT+nSnC9Bi6wvV eETwXufydtSSHK29MSzgYXeHfz2CIAg9gUoFo= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=kYfY0b0Eru1BCiIQKg5qi1VUsfECojT48kATcNDnRmNHEyXV3Frd7cLtA6gGoKAaK3 KpfZ4oiYDYqp9W5KixsRYCNBhetJMVSyFIPgHHdhmtLBojRa2joYMfIIDUh+VBtfctJf NVluEh5eF+MehEcrZI2E3FNZ+PrqaB5/37orM= Hello! I need to install my application to /Users/<current user name, who launched the installer>. I have searched the list, I know what i want to do is wrong, but i can't install my application for all users. The reason is that i have to create /Users/<username>/LaunchAgents/my.app.plist, and create it in user's home directory - because later my application will need to have privileges to delete this file, or to rewrite it, depending on if a user sets the checkbox "Launch app on startup". My application (like every other app from /Applications) is not launched with root privileges - user just "doubleclicks" it, therefore it can't modify the Launchd's *plist file in /Library/LaunchAgents/..., but it can do that to /Users/<username>/Library/LaunchAgents/... Thus i'm having an issue determining the user's home directory during installation. Of course, if there was a way to modify the "root's" .plist in /Library/LaunchAgents from an ordinary app, i wouldn't have needed all that "dancing around with a tembourine". What is the most reliable way to get that user directory in installation script? I was thinking to do it all this way: install the stuff to a temporary dir, and then copy it altogether to the /Users/<username> via PostInstall script. But the $User variable doesn't give the real username out, neither does $home. Looking for the answer I have found a command id -p that gives in one of its lines, together with the text "login", someone's username (in a second column). In my case, on my system this was the needed username - a name of a user, who had started the launching process, but i am not sure it will be that way on everybody else's mac. If it works for everybody else, i'd use grep | awk or something in a script, but i'm still afraid that it's not a reliable idea. Could you give me a hint, what is the best approach? Or, if there's no way out, how could my application modify (create, delete, overwrite) not user's, but "root's" plist (in /Library/LaunchAgents/my.app.plist)? Thanks! _______________________________________________ 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: Everything installs in /Applications, but not *.app bundles
by eveningnick eveningnick 31 Oct '10

31 Oct '10

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:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=2n+I6dsM1l2BtIBjX7tH9vdf/4dgO4kLwii1uT9dhZs=; b=hEX4Z/SQH3/tCTwRLJCIUQoUN1LrQisH0M8zsTumcbO9oaLwwrCRcsTekHccQRV4Vt TzRuKcEin2DX5fufhN/wRBuyAmOyc06ghsY9gKBGe5yQlff9Zl25r5BYwLok0o/n0Pyh mZVtJ3gIpx0kkLhDLKtAq5JkEA81UQS2KNEVM= 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 :content-type:content-transfer-encoding; b=iBcNVdNtYNMtzhIlEM5opcUk5nr076+XtHYPVxI798ZRj6qIcR2YttC8CzM9SXRFtQ wuqdMpQKMSaGiQmRi8mZPq0EOK9QmIRiTJgKUl1Zmbox9gxvYXvFILS8TwZKffOqCRca ScDR1SRv/a927Yc83Emem+IWsLf7fr4IrzWUk= >> If you look at the Installer logs, does it say that the application was relocated during install to another location (like where another instance of the application already exists)? >> >> If the answer is yes, this is a known issue that can be addressed by unchecking the option to search for previous instances. >> >> That being said, I'm wondering whether this "bug" is going to make it to the Mac App Store. > > ***Speculation ahead*** > > I'm betting not, because I'm betting the Mac App Store won't be using Installer.app or /usr/sbin/installer at all. > > The leaked guidelines for apps that can be submitted for inclusion in the Mac App Store say all apps must consist of a single, self-contained bundle, and may not install files outside that bundle. This makes sense, since the demo last week showed apps being installed without any prompt for admin credentials. > > This means the apps will be installed with a simple copy to some place the user has "write" rights, and removed with a simple delete operation. > > More complex software that requires an Installer package simply will not be available on the Mac App Store. Thank you Greg and Iceberg-dev. That was the problem, i unchecked the checkbox "Allow relocation", and now it works perfectly! _______________________________________________ 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: Help needed for accessing /Contents/Resources of a package.
by Iceberg-Dev 30 Oct '10

30 Oct '10

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:received:received:mime-version:in-reply-to :references:content-type:message-id:content-transfer-encoding:from :subject:date:to:x-mailer; bh=ctimXWOQ8MmN4Z30bSHeAfI+m/0G1S70w9Zp0F/MGuk=; b=SkyuYnTWbyW2V4mekIHhDhyPQ2m9aDq9mqkq0XGDF4VoY/AzF/j0TVCGumg5N5D9b+ z7tQcuVmtIJqs2FqwC1ERU+jrAXQT0n1msycTTae/zWiTr94+6nJrdawKKBoEc+9CoB9 XmZWoXik/Ppd2fUec8udkTWR0nsKQzSDuFhig= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:content-type:message-id :content-transfer-encoding:from:subject:date:to:x-mailer; b=q7dByEtZvG+f0cMglAjHb/NbLe6CDF1OlWpzVc3eKvWdIDZQlgmaXn6+PD5yEKh/Hy PHP8EmGk1OdmrS/4xYJ4uslVOteHGl3oX61bpNA5ioPdboevtNb1O4VWfQpOt/QFBgOU 0H5sfpSDPJdZGvzvZlz3nHP4gFaF8jwFe2G7w= On Oct 30, 2010, at 8:00 AM, Falguni Panchal wrote: Hello, _______________________________________________ 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 want to create an installer package in Iceberg which needs to add one file in .mpkg/contents/Resources. Now I want to use this file in my preflight script. I heard that $ {RECEIPT_PATH} is a variable which holds a value of package/ Contents/Resources. I used this in my script, but it fails. Please guide me how to reach to /Contents/Resources of a package in script. $1/Contents/Resources/ works for packages. It probably works for metapackages. This email sent to site_archiver(a)lists.apple.com

1 0

Help needed for accessing /Contents/Resources of a package.
by Falguni Panchal 30 Oct '10

30 Oct '10

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: Unable to enforce version checks in metapackage
by Iceberg-Dev 29 Oct '10

29 Oct '10

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:received:received:mime-version:in-reply-to :references:content-type:message-id:content-transfer-encoding:from :subject:date:to:x-mailer; bh=lxKjLowujIvlZOPs+PcpIPtQUy9wkXg3hN4ucRN1g6U=; b=Vmrl/akGswCZGWKZRQW4DFYGwvS2iUeqM1BvXhJ/S2N7G5iJq7VOC9E6TgWMQfrqPb cUvlRpzscEd/kw7APjDk+macawRA+k/Syt6IRAiGOgF/746uiKtZnk/esh0lR+bAGock dgxww1YrdX2DnzmdKngd6giPUK7C7tQuU5x8U= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:content-type:message-id :content-transfer-encoding:from:subject:date:to:x-mailer; b=BSVbaU3/2x3LtbLJt39IliYBCjQWjo1U2HhdtMHZwsYMd/0zXeEPuYSQC30qRo/5wx nxqiKi/jym+OvfaM/v2I7t9r4ods4cKqwW6eL16nA5P4+ubqddRk2rTEEc/drvhsCZ4N Uds6bRo17+Ilc1/hYnOzla1wo2MtAcFGw71JY= On Oct 29, 2010, at 3:02 AM, Monte Benaresh wrote: Hi All, 2. No alert box. _______________________________________________ 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.… Some of you may have seen that I am interested in creating a metapackage that only installs its components when they are newer than what is already installed. Thanks to Stéphane for his replies to my last post. Originally, I tried twiddling all the available version numbers in Iceberg. I found that the only instance of the version number that is checked for simple packages is "Short Version" under "Display Information." However, as other developers have seen, this mechanism is absent when installing a metapackage, and all components are installed regardless of whether they are older or newer. Today I thought of using the InstallaitonCheck script to enforce version checking. First I simply modified a working script to 'exit 113' and defined a string for it. This all works fine in the simple package, but when placed into a metapackage I get the following behavior: 1. Log error: Oct 28 17:44:22 Monte-Intel-Mac Installer[2793]: Package Authoring Error: Infinite loop between <choice> attributes and mixed state aborted. 3. The component generating the failure is grayed-out. Hovering over its entry in the "customize" list shows tip text with my error message string. I did more experimenting, and #1 happens whenever InstallaitonCheck returns a non-0 return code. Are metapackage installs really so badly broken or are there some other rules I must abide by when dropping components into a metapackage? My goal is simply to combine multiple installs for the convenience of the user while preventing back-rev components from getting installed. An InstallationCheck script returning a non-0 return code should not cause that kind of error. Using an InstallationCheck has always been a solution with metapackages to disable a package (for instance if it's not compatible with the current OS version). The error message is a bit mysterious. It looks like the kind of message you might get if you were using a distribution script and having a package P1 whose state depends on the state of package P2 and the state of P2 depends on the state of P1. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Unable to enforce version checks in metapackage
by Alexander Cohen 29 Oct '10

29 Oct '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com I've been having the same problem and it has actually become a really big one because newer libs and frameworks are being installed over newer ones. But i've been thinking and this is completely untested, but are any of the packages set to disabled but selected. Mine are all like that and the version checking is not hapening. Is it possible that only when they are enabled for user decisions on install or not that the version checking will happen? AC On Oct 28, 2010, at 9:02 PM, Monte Benaresh wrote: > > Hi All, > > Some of you may have seen that I am interested in creating a metapackage that only installs its components when they are newer than what is already installed. Thanks to Stéphane for his replies to my last post. > > Originally, I tried twiddling all the available version numbers in Iceberg. I found that the only instance of the version number that is checked for simple packages is "Short Version" under "Display Information." However, as other developers have seen, this mechanism is absent when installing a metapackage, and all components are installed regardless of whether they are older or newer. > > Today I thought of using the InstallaitonCheck script to enforce version checking. First I simply modified a working script to 'exit 113' and defined a string for it. This all works fine in the simple package, but when placed into a metapackage I get the following behavior: > > 1. Log error: > Oct 28 17:44:22 Monte-Intel-Mac Installer[2793]: Package Authoring Error: Infinite loop between <choice> attributes and mixed state aborted. > > 2. No alert box. > > 3. The component generating the failure is grayed-out. Hovering over its entry in the "customize" list shows tip text with my error message string. > > I did more experimenting, and #1 happens whenever InstallaitonCheck returns a non-0 return code. > > Are metapackage installs really so badly broken, or are there some other rules I must abide by when dropping components into a metapackage? > > My goal is simply to combine multiple installs for the convenience of the user while preventing back-rev components from getting installed. > > Thank you, > > Monte Benaresh > PACE Anti-Piracy > > _______________________________________________ > 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/alexcohen%40toomuchspa… > > This email sent to alexcohen(a)toomuchspace.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

Unable to enforce version checks in metapackage
by Monte Benaresh 29 Oct '10

29 Oct '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Hi All, Some of you may have seen that I am interested in creating a metapackage that only installs its components when they are newer than what is already installed. Thanks to Stéphane for his replies to my last post. Originally, I tried twiddling all the available version numbers in Iceberg. I found that the only instance of the version number that is checked for simple packages is "Short Version" under "Display Information." However, as other developers have seen, this mechanism is absent when installing a metapackage, and all components are installed regardless of whether they are older or newer. Today I thought of using the InstallaitonCheck script to enforce version checking. First I simply modified a working script to 'exit 113' and defined a string for it. This all works fine in the simple package, but when placed into a metapackage I get the following behavior: 1. Log error: Oct 28 17:44:22 Monte-Intel-Mac Installer[2793]: Package Authoring Error: Infinite loop between <choice> attributes and mixed state aborted. 2. No alert box. 3. The component generating the failure is grayed-out. Hovering over its entry in the "customize" list shows tip text with my error message string. I did more experimenting, and #1 happens whenever InstallaitonCheck returns a non-0 return code. Are metapackage installs really so badly broken, or are there some other rules I must abide by when dropping components into a metapackage? My goal is simply to combine multiple installs for the convenience of the user while preventing back-rev components from getting installed. Thank you, Monte Benaresh PACE Anti-Piracy _______________________________________________ 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