February 2009 - Installer-dev

Re: updaters
by Dodger 18 Feb '09

18 Feb '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=i1hOEeNaMYMHV3H3EMdiwXzudn+4ftckfJeWWm/MEWE=; b=OmCJfpHbVWbtJUuRZQWVra9kP223AAHgoj7GQ1YIHNlNw6LnGkOzqnyBLuA8NFF1e5 i3fhwaOWqsXvy5m4CAUOTw0byj/6S3/xnD8R6xkvadfMP8iTZhpV34MKhyVTeukjs97o 0/BUZBL225342lFfVmRdg/cKFny7iyu0zTr9k= 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=bkoMvK9e0Wp8nMwdOIvd4QizdQR2I/BU6FFJgztEpcH3tonc9AyHCnJF7baLvS4pr9 343/z90ko0Q83H70gWePd+q6wrCJ/lanq+hkozN5YSaVVLndHGnR7Yq2Gr6885fxXGSd cHVKXcQ5joqqVrGfBIui7OolqknBQlkb8dpkQ= 2009/2/17 Crawford Kyle <kcrwfrd(a)gmail.com>: > Well said Greg. > > I've been thinking about this. Is there a way Apple could disallow these > arbitrary installer scripts and still support the scenarios that seem to > require them? Perhaps this warrants a separate thread. If you mean disallow any external scripts, well, there's a reason they're allowed: to allow for things they haven't foreseen. I know my problem would be very unlikely to be handled in the packagemaker app, for instance (i.e. applying a morph target to an Alias Wavefront Maya object file and saving out the results). If Apple foresaw that need, they probably *still* wouldn't include the possibility because it would be so rare. On the other hand, if you mean disallowing doing specific certain things, well, then that becomes an arms race. You disallow wget, they include a perlscript that uses LWP. You block outgoing fetches to port 80, they set up a proxy server on their own site to redirect from a different port. Etc etc. You block all offsite access, you may very well outlaw a perfectly valid approach to fetching the latest update patch and applying it. -- Dodger _______________________________________________ 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: updaters
by Iceberg-Dev 18 Feb '09

18 Feb '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:received:received:in-reply-to:references :mime-version:content-type:message-id:cc:content-transfer-encoding :from:subject:date:to:x-mailer; bh=MXYLmSqkatJ0+MAQeIeEEeRUHlIUX2rtFPAAk7kknlY=; b=W3ziC3s05xsz5bR41w5IHzKlzsPrl3XsFDo9QzD8uPGnXizTVi68KfNVlYQCM15fvH 7iDSldotMHElt2CATUFE7MBL5kFI6qIPcBId5PeipsB0ig6K6tHldodAh3/m9itu0N4d HHTaXPPV12qbgRMt6Md8BROb0hzi8UlJJuqtM= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=in-reply-to:references:mime-version:content-type:message-id:cc :content-transfer-encoding:from:subject:date:to:x-mailer; b=fkvYR9fugTqHODy+tTDIJfFz9ubAhMfkMAKwaDPi4GrLdlZ7kmHnjkMadMXzW3zTm1 yY2nfkLxh1tsvE4VU6PnbJYRDThnn7DAPLXvnl7RvhH83qnadJ/HuUA6Fn6HR/bzNzRl 4X3Ay9UmFp5DOJS6M8q11aRT5GVAcjKVptzFQ= On Feb 17, 2009, at 6:45 PM, Greg Neagle wrote: What's possible to do is this: - have a .bom file that describes what will get installed. - install nothing from the pax payload - install everything from a postinstall script. - when you display the list of files from the UI, it lists the files - when you run the installation, it installs nothing and succeeds. _______________________________________________ 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.… As a systems administrator, I expect the changes an installation package makes to be documented in the Archive.bom (for bundle-style receipts), or in the receipts database (for Leopard-style flat packages). I don't expect to have to reverse engineer what a postinstall script installed. It just requires to build a standard package and a package that installs nothing. You then replace the .pax[.gz] payload with the one from the empty package. When you install this package through Installer.app (tested on Tiger): This email sent to site_archiver(a)lists.apple.com

1 0

Re: updaters
by Eli Bach 17 Feb '09

17 Feb '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:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:subject :mime-version:date:references:x-mailer; bh=kirBnhaJVkzA06IhLwMWZPrvAIGD6XgxbiXuns6Qeos=; b=qj2I7D83OnGKLpznPTxA9/t91EFrbwZwGt5Uy3icNZ+pxxjpfLS3o7ZvcipHAa13oC 9RybWVXudKDlybYgJJ+0ubhRzt5aEkTXwTE3NpgKjkfoz6HXqL19Uf76mLWOb2UwJkWY OGWSioePFDjC6XUV57QEW+GKdrYa0jDGoPbNQ= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:subject:mime-version:date:references :x-mailer; b=vhUdFbLBYpj9YVtyd5QZDzWnoxNYGNv0Fep0juKP4xD7DGd/Srou3urC1jL+Mrx47R EvKY+N20llO2vT4HcGz3c7Bjb9jBxV9wQxHU+JzQn/Ll6LzEva+2ipDom44JqyljyvWb CWdM7bnbaJ3XfAPSmmpfl/I0YRIKi3E4Ui9jM= On Feb 17, 2009, at 12:28 PM, Crawford Kyle wrote: Well said Greg. Eli _______________________________________________ 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've been thinking about this. Is there a way Apple could disallow these arbitrary installer scripts and still support the scenarios that seem to require them? Perhaps this warrants a separate thread. Kyle Then Apple would have to 'know' all the things developers would want to do in postinstall scripts, and then instead of having a postinstall script, developers would just be able to do postinstall 'actions'. I hope this doesn't happen, as there will always be something a developer has to do (well, that somebody in marketing wants to do) that won't be covered by whatever list of actions Apple comes up with. I think PackageMaker 3.0 kind of started along this path, with flat packages and the pre & post-install 'actions', and I found that the actions listed (and offhand I didn't see how to add new actions myself) were no sufficient (I needed to whack the permissions on a file because building the package using the GUI would helpfully 'fix' the permissions to be wrong, before I was helped by somebody on this list to build the package using the cli with the option to not verify permissions). But things like this will always be a tradeoff, between the capabilities of tools and how those capabilities are used (or possibly abused). This email sent to site_archiver(a)lists.apple.com

1 0

Re: updaters
by Crawford Kyle 17 Feb '09

17 Feb '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:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=2gPbe+K8PPdoDtNx2ozfpTSs26RGKigxcr2ZbTnVyPo=; b=xXIXJv0rQlaOvKQahGodoYPLaNnGhNvkzsWFtvEnPZCi/TBj++wCa9sRdu89DvM6WJ XX49iVeHhldkg8aJ5YESVMUjQ3Lh80AmqjfbkF85ykZk/biBq/2AdQIOqzBLnU5tWxB+ H8QOvZxFcrHYt4V29YPa4bKuZTJr8ecPpcwEQ= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=unoygAiKWVjg409vOr3cSA6J+D1Av2Xl4Tve3No0QZOKOfhTwr1ye1ubec6Sofvdth 3DJmu0uSVK8lx+EAjVhJ7QJjc/U8IfguiwukWpfjviij9lMase8MoTr+/ayyraBE+110 qdFuQr6xVnD8eQZIV29VlkEiyZzTg8/xALGrM= Well said Greg. Kyle On Feb 17, 2009, at 12:45 PM, Greg Neagle wrote: That's what I mean by violating the spirit. But that violates the spirit of installation packages. -Greg On Feb 15, 2009, at 11:15 PM, Dodger wrote: (you _could_ with a postflight script, but that's really violating the spirit of install packages) How so? I'm using that exact sort of functionality deliberately. In my case, I'm installing 3D assets that are derived works based on other ones, by making the installer include only the deviationa and not the original, thereby making it so I'm not redistributing the original content. -- Dodger _______________________________________________ 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/kcrwfrd%40gmail.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.… I've been thinking about this. Is there a way Apple could disallow these arbitrary installer scripts and still support the scenarios that seem to require them? Perhaps this warrants a separate thread. As a systems administrator, I expect the changes an installation package makes to be documented in the Archive.bom (for bundle-style receipts), or in the receipts database (for Leopard-style flat packages). I don't expect to have to reverse engineer what a postinstall script installed. There's nothing stopping a developer from doing this. Heck, there's nothing stopping a developer from shipping an installer package that has no payload at all, but whose post-install script downloads random content off the internet and installs it at random spots in my filesystem, and then uploads the contents of my home directory (or any portion thereof) to the developer's server. 2009/2/13 Greg Neagle <Greg.Neagle(a)disneyanimation.com>: This email sent to kcrwfrd(a)gmail.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: updaters
by Greg Neagle 17 Feb '09

17 Feb '09

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com That's what I mean by violating the spirit. But that violates the spirit of installation packages. -Greg On Feb 15, 2009, at 11:15 PM, Dodger wrote: (you _could_ with a postflight script, but that's really violating the spirit of install packages) How so? I'm using that exact sort of functionality deliberately. In my case, I'm installing 3D assets that are derived works based on other ones, by making the installer include only the deviationa and not the original, thereby making it so I'm not redistributing the original content. -- Dodger _______________________________________________ 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.… As a systems administrator, I expect the changes an installation package makes to be documented in the Archive.bom (for bundle-style receipts), or in the receipts database (for Leopard-style flat packages). I don't expect to have to reverse engineer what a postinstall script installed. There's nothing stopping a developer from doing this. Heck, there's nothing stopping a developer from shipping an installer package that has no payload at all, but whose post-install script downloads random content off the internet and installs it at random spots in my filesystem, and then uploads the contents of my home directory (or any portion thereof) to the developer's server. 2009/2/13 Greg Neagle <Greg.Neagle(a)disneyanimation.com>: This email sent to site_archiver(a)lists.apple.com

1 0

Re: Weird...
by Dodger 16 Feb '09

16 Feb '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:content-type :content-transfer-encoding; bh=0GGRLOWTZvWSW0Z1wLDO1ploo08yvIeckb8xcLCPbDU=; b=Kb2J6twQFV8vQCjOr12skadpD0tirLtlz091vhhfcPfsMbPsoggfkvTo+lzPhViMSM H94HEStXjwbiwSqEJFOXzY7uf+PH8253RCPW5ZVs9tdy5/QbhaRBxwVqubyM1ritrQQ+ up7F1UjozOjtnbmk1B7XipDP7fzohrBCvg5IE= 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=Fjky44ijdWMP8rjzcSLzYibNMm3UJ3cheb+GhjGreCe2tlywmlNEnd7tq00VHQvHWx 9q4HV3xxdwRyNhzicIVYKOr/hii/6qFilEwSkLKHk4JS0j7ytcauy3mh647JC9FMhWzy Xum01bRR2QFrppIfqpygV4Syc2hfkMxRnoi0s= Aha! I found out what's going on! For some reason, the Volume Check script runs, but doens't block the ability to continue! Since the find call was taking so long, it was returning later. I tested it by putting in a sleep 10 in the script to see if it would tile itself out. It's not really timing out, it's just that it gets to the install section *before* the script has returned *at all* This is undesirable behaviour. The Volume Check script should complete before allowing the user to continue. Does anyone know of a way I can force this to happen? 2009/2/16 Dodger <el.dodgero(a)gmail.com>: > Attempted at a volume check perlscript that was to do the following: > > - Run locate for folder, then check matching foldrs for prerequisite > - OR Check standard assumed standard location folders specifically for > prerequisite (in case not in locate db) > - OR run find on whole drive (skipping things like /net that slow > things down) looking for folders. > > When it's found, write prereq location to /tmp/installinfo and return 0 > Return 1 if it's not found and the file is not written > > Preflight script set to consider 1 failure (because that's the right > way to do it) > > Here's the thing... > > It's running the preflight script and returning successful in almost > no time, but the file is not written. > If I remove the slow find option, it works as it should, and if the > file is not found it returns failed and thus displays the "sorry" > message. > > Any ideas anyone? It almost seems like the installer is timing out the > script after a second and *assuming it was successful* > Which is really $%&%ed up. > > -- > Dodger > -- Dodger _______________________________________________ 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

Weird...
by Dodger 16 Feb '09

16 Feb '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:content-transfer-encoding; bh=7xjMzkyIH0c8N6gkvAMi6+EY1xLCMWqz6kKXu8Cd8es=; b=wP3lGeiX6GGXlIx08oBaSZKcLdtFsX4R/+6ZoDYblCwiX11bfmuOsClMdjor12iLQF vKTPiLXsb3xUjxb40Tr+GjrjIjJk0bE2HXegbZu8bZ0VPkTKbaJfiu92WmHHeRAl3ywx pW9dtqbDR1KgVyzKsvxAGBj0+DX5Gj/QzV8nI= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=mYSbD9McbjvhVNDjKJy92Vs/Qrx08mz3hz7/alXyQn7zSxvmrbm/sOcOF1XNHUk5jP R8nH2+R7vQAj42lQc2sjWcUN80pYoEPQZfUqJFYZNV0kzvsAsGLMa8RtDeTu2ksx9KJQ 4mD6GrIp8rTZ+r4DoCd4bT2YnsuZJKs3ALYq4= Attempted at a volume check perlscript that was to do the following: - Run locate for folder, then check matching foldrs for prerequisite - OR Check standard assumed standard location folders specifically for prerequisite (in case not in locate db) - OR run find on whole drive (skipping things like /net that slow things down) looking for folders. When it's found, write prereq location to /tmp/installinfo and return 0 Return 1 if it's not found and the file is not written Preflight script set to consider 1 failure (because that's the right way to do it) Here's the thing... It's running the preflight script and returning successful in almost no time, but the file is not written. If I remove the slow find option, it works as it should, and if the file is not found it returns failed and thus displays the "sorry" message. Any ideas anyone? It almost seems like the installer is timing out the script after a second and *assuming it was successful* Which is really $%&%ed up. -- Dodger _______________________________________________ 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

Annoying trade-off in user interface
by Dodger 16 Feb '09

16 Feb '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:content-transfer-encoding; bh=QQVPrdNc3oWqszodIKMWd3EXFBDUejTJVsu/DC4ml+A=; b=SzypEZlTqkuZWBuHucixrXYHdlHWyXFQUsuKE2/YmDxuRLZoXdeczQHa5osnDlKV4V irCF+gMJNYYMpXee476WISBdaPs58e0qZsugh5eHWCyUPG8uSCwiGNU7REyUqLHC9DZn rXmLe5QHk1C0GrXRiYYCPcE4hA958jg6d/viY= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=TItLFkfIX1fubEwH/QdG2u9UyBPljytv4hkSHI0J+aURg8EKfyaYEYKDO87+aI/6RZ G5lS3JTJy4LPZG8qzWkrD3um50AaYXfydR7aJZXYNiTnesL84Gz28Vtt3jxJ8fp4i6E6 8L2mDw8uudtE0h4PP+OZDCcGiwqnXurixMD4M= Hi, all, I'm wondering if anyone can help me with this little issue I'm having (actually, 2 little issues) Okay, the first one is that my distribution requirement script seems to have to be external -- I have it living as an invisible file in the DMG itself, which would be mounted with the same name all the time and all, so this should be OK unless, for instance, the user already has an extrnal hdd mounted that just happens to have the same name or something. That would make it fail. This seems a bad way to go about things, but this script has to be there for things to work properly. It seems like a cheesy hackish solution though. Effectively, the script finds a prerequisite and stores it's location in a file in /tmp so that the postflight script which constructs the product's file from the other one knows where to get it. (think of it like a patch into a new file sort of thing, because that's a close description except that it's not actually a diff/patch) So there are these drawbacks to this: 1) If the user has it installed in a nonstandard location, like on an external hard drive or not under /Applications, my "find stuff" script can't find it. I don't want to do a full drive search, and I cannnot expect locate's DB to be up-to-date or even be sure that locate/slocate is installed for certain. I know this because I just tried to use /usr/bin/locate to find the required file on my machine and it didn't return anything, and it's very definitely on here. 2) It's hackish and cheap to have a perlscript sitting invisible in the root of the DMG just so it's there. 3) If the user already has the volume name in use, the DMG will mount with an alternate filesystem name and the script will not be found. 4) The user must run the installer from the DMG (or at least have the DMG mounted when running the installer) Now, if I could figure out what CWD the installer runs the volume check script starting from, and if that were one consistently relative to the .pkg drectory, I could get past 2, 3 and 4 by putting the script *inside* the .pkg directory itself. So that is question #1: Can I put a script inside the Whatever.pkg directory of the packagemaker installer and run it, and if so what path do I give it. I.e. will the PKG run with it's cwd in itself? Right outside of itself? Where? Now, I realise that I could go out and hunt down the location of the required file from a preflight script instead, and that the preflight script would have the install directory given to it as an argument, and that that would avoid all 4 of the problems, but it comes with it's own problem, which is pretty big in my opinion: 1) Preflight scripts fail in an unfriendly way Preflight scripts, when they fail, simply show a big Triangle-! and say the script failed. They do not tell the user what's wrong, nor does PackageMaker provide any mechanism with which to tell the user what's wrong (whereas the above volume check lets me set some JavaScript to handle the exception and tell the user "The required file was not found. Please make sure blah blah blah" It seems weirdly un-apple to make it so that we have two choices: Unfriendly input or unfriendly output, and we can't have the friendlist of both worlds. So, if anyone knows a solution, I'd really love to know. And if you happen to be a Poser user, I'll happily give you a copy of the content for your input! As much as I think the NSIS scripting language is quite possibly the worst scripting language I've ever seen in my life (GOTOs are a way of life in them), I kinda wish they would make NSIS for Mac. I can customise the hell out of an NSIS installer on Windows. -- Dodger _______________________________________________ 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: updaters
by Dodger 16 Feb '09

16 Feb '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=vz69kcreuXwyzh+CtE26zXZI7RAfWiIf9XuJJcCY8qk=; b=kOYprX14drLCgdcFZ/aq2LtL1R9HrOC0pIHDq8hYmoMjw9ZojQYSz1ZJXgGtOk375r DQxf2zdzwOq/MWa5auDJnL4FjmK3qmTi3JscBT4VBIhmzPv96ytsvXfy8rnFgdeSA5tq BCjw1E5unD9GN0vJpjO+Mr+ZBh2n8fMQNzWGw= 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=QR0MXxUpUb/6CZi5Z4sw1xYBKMeNFTd3jl/g3tGoFdiGGlAcMgHG/LU9rAFggJJjWj yK0olk5H306KWB3mcPUd1uVIHDjZJd+/AYQcLh7fTnwnnFDGHpPZ8bHqAjQ0PNgLSt4G BDf2UcUx7g72OB3LjgF0zugTlfucO/OwM/xuM= 2009/2/13 Greg Neagle <Greg.Neagle(a)disneyanimation.com>: > (you _could_ with a postflight script, but that's really violating > the spirit of install packages) How so? I'm using that exact sort of functionality deliberately. In my case, I'm installing 3D assets that are derived works based on other ones, by making the installer include only the deviationa and not the original, thereby making it so I'm not redistributing the original content. -- Dodger _______________________________________________ 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: Understanding RunAtStartup
by Iceberg-Dev 14 Feb '09

14 Feb '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:received:received:in-reply-to:references :mime-version:content-type:message-id:cc:content-transfer-encoding :from:subject:date:to:x-mailer; bh=JzwodccJyTCSnNGms02jo/sa0NIHABuwpgAzY+Pf51E=; b=EwmfCdVLy7/+PeTjMhajICeRuKu3n5t1jMLNP+Uqyyn5Qf5X0hOQEVDuoD9DxNH43z CRDq3F9G0rT3T+0dzl3ScNIA6K9emIcj29RO+YBokbI0G9tFexoZ+Wb+cNQZOCQvUTW2 O3+O1KMPBQPjktx63R+KDRX2ToDo2F1hK75d8= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=in-reply-to:references:mime-version:content-type:message-id:cc :content-transfer-encoding:from:subject:date:to:x-mailer; b=hqmfa0CBsjIzXrq/qsOo4KTSLp6LJ+xr4Y3IiQOW0q5LtELLL0iY8g8FyAFZxS9Cy3 rtp43mV5hVuvlrRuH4nW7xbVIa9OtUkXAGCywsrToKbqO04X2PPI27T5bPxPZfwvl9fv x4c2OavKiH/NI4nKoqNx/CXcSkQMJHRDGVG5Q= On Feb 14, 2009, at 10:06 PM, Fred Licht wrote: -Fred On Feb 14, 2009, at 4:10 AM, Iceberg-Dev wrote: On Feb 14, 2009, at 1:56 AM, Fred Licht wrote: IIRC, this script is launched on the next restart. It is only launched if: - you required root authentication for the package - the package requires a restart. Again, your best bet is to install a package with a RunAtStartup script. You could also try playing with the ENABLE_RUNNER_DEBUGGING env. _______________________________________________ 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.… Thanks for the replying. I know and understand what this RunAtStartup purpose is. I am asking if anyone knows what the installer does to the system to prepare for the script to run at start. Does it create a startup item, enable a launchd script, put the script in a special location for the reboot to use. Hey Everyone, I know that Apple's installer will respect the "RunAtStartup" script for an installer script. Does anyone know what actually happens with that script and where it is placed to be run at boot time? For the location, you can use fs_usage to check where the file will get installed. This may require a remote connection as Installer.app may or may not copy this file after the user has been logged out. Since it's a script, you should be able to modify it to log information that could prove useful. This email sent to site_archiver(a)lists.apple.com

1 0