February 2007 - Installer-dev

Re: creating alias during installation
by Bill Coderre 14 Feb '07

14 Feb '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com [blackbook:~] bcbc% ls -dl /Applications drwxrwxr-x 180 root admin 6120 Feb 12 22:30 /Applications/ The Installer is not enforcing this. Unix is. _______________________________________________ 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.… On Feb 13, 2007, at 6:58 PM, John Daniel wrote: It would be nice to have a drag-n-drop-type installer that doesn't need administrator rights but can install into /Applications. There might be more to it than this, but I just asked Unix, and it told me this: Now according to this, only root and admin users can put things into / Applications. Dragging stuff is usually not much of an issue for most Mac OS X users, since they usually have one single account and have admin set on the account. So if you had a "no authenticate" installer, it would run as the user. This would work most of the time, but not if the user was not in the admin group. So it's incorrect to have a "no authenticate" installer install into any location that a user might not be able to write to. If the user is non-admin, almost the only place that they CAN write is their home directory. (Almost) This email sent to site_archiver(a)lists.apple.com

1 0

Re: creating alias during installation
by John Daniel 14 Feb '07

14 Feb '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Feb 13, 2007, at 12:01 PM, Luke Bellandi wrote: That is why I went to an Installer. John _______________________________________________ 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.… Actually, it depends. Apple's recommendations for package distribution are not that cut and dry. The sort of distribution mechanism you should be using depends on three things: [1] the complexity of the install you're performing [2] your desire to present the user with addition information or plugins during the installation [3] the computer-savvy level you expect of your customers So for non-complex projects (e.g., a self-contained application), where you don't need or want to display a read-me, license agreement (yes, that functionality is available in disk images as well), summary panel, or use installer plugins, and where you expect users will have a good understanding of how to use the file system, then a drag and drop installer is an appropriate avenue to consider. For other situations, you may need/prefer to use an installer package, if only to hold users' hands through the installation process. Installation is an intimidating process for a lot of novice users. Using the Installer as opposed to asking them to drag and drop an icon can be somewhat reassuring. But I still don't fully understand the PackageMaker installer. My first installer worked great. But, I was using it incorrectly by installing into /Applications with No Authorization. It seems like the only correct option is to authenticate as administrator and install applications as root. My application doesn't need that and a halfway savvy user would know that and wonder why it is asking for administrator rights - as well they should. It would be nice to have a drag-n-drop-type installer that doesn't need administrator rights but can install into /Applications. I have an installer for Privoxy that definitely needs PackageMaker. It should authenticate and run/install as root. My dilemma is a simple installer for those intimidated novice users. If they don't have rights to install in /Applications, it will tell them. If they do have rights, it should install as easy as dragging-n-dropping. The files it creates should be owned by the user installing, whomever they might be and whatever their uid might be. Perhaps when I get time I might try to create that with my "incorrect" no authenticate installer and better scripts. This email sent to site_archiver(a)lists.apple.com

1 0

Re: creating alias during installation
by John Daniel 14 Feb '07

14 Feb '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Feb 13, 2007, at 11:57 AM, Andy Davidson wrote: John _______________________________________________ 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 have noticed that trick also, which seems very nice. I would love to find some nice clear instructions about how to create the Finder window with a background image and to have the window configuration remembered by Toast, etc. What I have done is create a read and write disk image for the installer. In the top level of the image, create a folder named "background" or something, inside the install folder. Put your background image in that. In the Finder, set the background image for that window. You can also hide the toolbar, set icon sizes, etc. Then, in the Terminal rename the "background" folder to ".background". Then use hdiutil or DropDmg to convert that read and write disk image into a compressed read-only image for distribution. When the user opens the disk image, it should remember the background, size, position, and all the other things. Finally, since you don't want to do this 14 times in a a row, you need to script it all. Also, that background image isn't locale specific, so don't put any text in it. From a developer's perspective, building a PackageMaker installer is much easier. Debugging it...I'm still working on that. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Two questions related to a mystery
by Peter Bierman 13 Feb '07

13 Feb '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com I'm using the following call: sudo pax -r -pe -f Archive.pax ./._filename. Install "fileA" into /Applications/Test/ with: - "fileA" having a Data Fork and a Resource Fork That is the bom file looks like this: . ._fileA fileA If I try to do this with PackageMaker, it works fine. -pmb _______________________________________________ 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.… At 11:24 PM +0100 2/10/07, Stéphane Sudre wrote: 1. Is there a way to extract the ressource part of a file (the ._filename file) from a pax archive without having it be transformed into a Resource Fork? My fear is that this is Filesystem related and that even logging into >console would not do any good. Dot-underscore files are "magic". Some versions of Mac OS X have kernel support for synthesizing or recombining them. That means that you can't always treat them like ordinary files. 2. Is there some magic incantation to have resource fork being merged back to data fork when you want to do the following thing: - /Application/Test being set as the Default Installation path and Test does not exist yet. If I try to do this with a Script involving /Developer/Tools/SplitForks, it does not work. When analysing the bom, only a difference with the checksum of ._fileA can be seen (this is the reason for question 1). It might be related to the order you're extracting or moving the files. See if you can determine if the ._ file is being handled after the data fork. I believe ditto has code to reorder extraction to ensure the resource fork doesn't come first. This email sent to site_archiver(a)lists.apple.com

1 0

Re: creating alias during installation
by Luke Bellandi 13 Feb '07

13 Feb '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Feb 13, 2007, at 9:47 AM, John Daniel wrote: <snip> - Luke _______________________________________________ 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.… Recently, I have noticed a nice trick some people are doing. They are putting a symlink to /Applications on the installer disk image with a background image consisting of an arrow moving the app to the installer link. Given this little trick and my PackageMaker failures, I am strongly considering going back to a drag-n-drop installer for simple Application installations. I read somewhere that Apple recommends that method. Actually, it depends. Apple's recommendations for package distribution are not that cut and dry. The sort of distribution mechanism you should be using depends on three things: [1] the complexity of the install you're performing [2] your desire to present the user with addition information or plugins during the installation [3] the computer-savvy level you expect of your customers So for non-complex projects (e.g., a self-contained application), where you don't need or want to display a read-me, license agreement (yes, that functionality is available in disk images as well), summary panel, or use installer plugins, and where you expect users will have a good understanding of how to use the file system, then a drag and drop installer is an appropriate avenue to consider. For other situations, you may need/prefer to use an installer package, if only to hold users' hands through the installation process. Installation is an intimidating process for a lot of novice users. Using the Installer as opposed to asking them to drag and drop an icon can be somewhat reassuring. This email sent to site_archiver(a)lists.apple.com

1 0

Re: creating alias during installation
by Andy Davidson 13 Feb '07

13 Feb '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Feb 13, 2007, at 9:47 AM, John Daniel wrote: Thanks, I'll check it out. .andy _______________________________________________ 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.… There is a shareware program called "DropDMG" from http://c- command.com/dropdmg that attach license agreements to DMG images, as well a many other things. Recently, I have noticed a nice trick some people are doing. They are putting a symlink to /Applications on the installer disk image with a background image consisting of an arrow moving the app to the installer link. Given this little trick and my PackageMaker failures, I am strongly considering going back to a drag-n-drop installer for simple Application installations. I read somewhere that Apple recommends that method. I have noticed that trick also, which seems very nice. I would love to find some nice clear instructions about how to create the Finder window with a background image and to have the window configuration remembered by Toast, etc. This email sent to site_archiver(a)lists.apple.com

1 0

Re: creating alias during installation
by John Daniel 13 Feb '07

13 Feb '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Feb 13, 2007, at 9:29 AM, sprockets77(a)mac.com wrote: John _______________________________________________ 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.… 1. Our legal folks have some very strict requirements about the user acknowledging a license agreement before the installation proceeds. I did find a way to attach a EULA file to a disc image, mentioned in the Software Delivery Guide, by adding resources to a UDIF disc image. This was incredibly arcane and involved running ResEdit in Classic mode, much too byzantine a process to use regularly. I could not find any information about doing this in a more modern way. (If one exists, I'd be interested.) Otherwise I liked the simplicity of the disc image delivery mechanism. There is a shareware program called "DropDMG" from http://c- command.com/dropdmg that attach license agreements to DMG images, as well a many other things. 2. But the larger reason I chose PackageMaker was simply because it provided an Apple-standard, fairly well-recognized user experience for installing an application. I also liked the fact that the packaging parameters were all contained in the PM project file, and it supported very nicely our legal requirements for license agreements. I'm not altogether happy with PackageMaker. I recently released an update to my software as an installer package. I have had a couple of failure reports already. One failure is still a mystery. The other is one that I worked hard to ensure would not fail - it did - once at least. I went to using PackageMaker because not everyone knows how to drag an application onto the Applications folder. I would sometimes get reports of "I installed the software, ran it a few times, went to run it today and it has disappeared!". What happened was they rebooted and the mounted installer disk image had been unmounted. I have not been able to find an elegant method for determining if the user is running from the disk image. It would have to be kludgy and I have releasing kludge. Recently, I have noticed a nice trick some people are doing. They are putting a symlink to /Applications on the installer disk image with a background image consisting of an arrow moving the app to the installer link. Given this little trick and my PackageMaker failures, I am strongly considering going back to a drag-n-drop installer for simple Application installations. I read somewhere that Apple recommends that method. This email sent to site_archiver(a)lists.apple.com

1 0

Re: creating alias during installation
by sprockets77＠mac.com 13 Feb '07

13 Feb '07

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

Two questions related to a mystery
by Stéphane Sudre 10 Feb '07

10 Feb '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Install "fileA" into /Applications/Test/ with: - "fileA" having a Data Fork and a Resource Fork That is the bom file looks like this: . ._fileA fileA If I try to do this with PackageMaker, it works fine. _______________________________________________ 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.… 1. Is there a way to extract the ressource part of a file (the ._filename file) from a pax archive without having it be transformed into a Resource Fork? I'm using the following call: sudo pax -r -pe -f Archive.pax ./._filename. My fear is that this is Filesystem related and that even logging into >console would not do any good. 2. Is there some magic incantation to have resource fork being merged back to data fork when you want to do the following thing: - /Application/Test being set as the Default Installation path and Test does not exist yet. If I try to do this with a Script involving /Developer/Tools/SplitForks, it does not work. When analysing the bom, only a difference with the checksum of ._fileA can be seen (this is the reason for question 1). This email sent to site_archiver(a)lists.apple.com

1 0

Re: creating alias during installation
by Stéphane Sudre 09 Feb '07

09 Feb '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On jeudi, février 8, 2007, at 10:42 AM, Bill Coderre wrote: [...] After all that, I forgot to tell you how to make an alias. This basically boils down to a simple idea: ln -s /path/to/MyApp.app ~/Desktop/Myapp.app [...] Note: ----- _______________________________________________ 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.… Don't make an alias. Make a symlink instead. The end user will not see a difference between the two, and the symlink is MUCH simpler to make. (I see Stephane disagrees.... Well...) Hmm, I don't disagree, it's just that an Alias is more robust than a symlink. I do agree that it was much simpler to make a symlink. But it might not be too complex to make an alias with the tool I've just uploaded (source code + Xcode 2.4 project) at: http://s.sudre.free.fr/Software/HelperTools/bristow.zip (BSD License + the NDAlias License) usage: bristow [-a][-u] <file or directory> alias -a -- Install an alias in all users home folder. alias will be read as a relative path. -u -- Install an alias in the currently logged in user home folder. alias will be read as a relative path. It's using the SystemConfiguration framework to know the current logged in user and if the answer is "loginwindow" it does nothing. It's probably not working when using installer through a remote user session (such as ssh). It's using OpenDirectory to list all the "real" users (real means uid >=500, yes this can be wrong in some restricted cases such as setting a uid to less than 500 so that it does not appear in the Login window in list mode). This email sent to site_archiver(a)lists.apple.com

1 0