April 2007 - Installer-dev - lists.apple.com

Re: Non-admin install to Home Receipt error
by don montalvo 28 Apr '07

28 Apr '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.0 (Macintosh/20070326) <happy-dance> David Bainbridge <dbainbridge(a)mac.com> wrote: On Apr 26, 2007, at 11:47 AM, Luke Bellandi wrote: _______________________________________________ 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 I see from the publicly available WWDC info, specifically (http:// developer.apple.com/wwdc/tracks/devtools-type.html) PackageMaker in Leopard adds some kind of new support for Home directories. > Hi David, > > Please file a bug about this issue at http:// > bugreporter.apple.com. Certainly we should provide a better > solution for this sort of workflow. > > Thanks, > Luke smime.p7s

1 0

Re: Non-admin install to Home Receipt error
by don montalvo 28 Apr '07

28 Apr '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.0 (Macintosh/20070326) my understanding is that packagemaker isn't designed to install into users' home directories. is this true? does packagemaker not understand "~"? i guess i can test but i've been doing pretty much as others have suggested...install into /tmp and mv using post install script to "~". don Luke Bellandi <luke(a)apple.com> wrote: Hi David, Thanks, Luke On Apr 26, 2007, at 9:32 AM, David Bainbridge wrote: _______________________________________________ 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 Please file a bug about this issue at http://bugreporter.apple.com. Certainly we should provide a better solution for this sort of workflow. > As has been mentioned in the archives but without a clear solution, > I am trying to install to the User's Application folder ( ~/ > Applications). To do this in PackageMaker I install to /tmp first > then with postinstall script mv application to the user's > Applications folder. The problem is the receipt is trying to be > copied by packagemaker to the /Library/Receipts folder instead of ~/ > Library/Receipts. The installer does not require Admin privs so > this does not work and I get this error in the log: > Apr 26 10:39:05 Mac-Pro : pkgReceiptMaker[518]: 2007-04-26 > 10:39:05.052 pkgReceiptMaker[518] Error 13 (Permission denied) > trying to rename App.pkg to /Library/Receipts/App.pkg > > What is required to avoid this error since the installer tells the > user the installation failed because of this?? > _______________________________________________ > 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/luke%40apple.com > > This email sent to luke(a)apple.com smime.p7s

1 0

Re: The common way to license/protect a commercial software
by Stéphane Sudre 27 Apr '07

27 Apr '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On vendredi, avril 27, 2007, at 10:01 AM, Filippo Ignozza wrote: Hmm, would "none" be a good answer? My $0.02 _______________________________________________ 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.… Hi, I am sorry if i posted this request in this mailing list but it seem to be the more suitable among the ones hosted in the apple developer section. If you can suggest a better place where i can post it, it would definitely help. i would like to know what is the most popular way in the Mac world to protect/licensing a commercial software What i need a 3rd part software to protect/licensing my product (not just the installation process), and to rely on it as the only way for licensing it. I Know many of them in the windows world (Sheriff-software, Aladdin HASP) but i want to know what is the most common for Mac OSX. Most of the products I've seen are using proprietary software solution (you need to enter a license number and voilà). Some solution may require you to go to a website first, enter a registration key to get a final license number but that's all. Usually, the solutions that are phoning home to confirm a license number is legitimate are quite criticized by "users". I had a quick look at Aladdin HASP and it seems to be available on Mac OS X too. For a pure software license SDK, the only one I can think of is the one made by Stone Design. Only issue is that it's Cocoa only AFAIK and your products seem to be X11 applications. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Get the package's NSBundle from a plugin
by Peter Bierman 27 Apr '07

27 Apr '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com -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 5:42 PM -0700 4/26/07, Mike wrote: If it breaks in the future I will re-write it as I usually end up re-writing things anyway to work around Apple's lack of features and lack of documentation. That's fine, but it leaves your customers who get the package from secondary sources in the lurch. Maybe you don't expect old versions of your product to be hanging around the internet on download sites and such, but for some developers, that can be very common. Or maybe if the Installer/Packagemaker docs actually *mentioned* when Installer closes the package, that would be helpful in making this decision also. But that's too much to expect from a 'world-class' company such as Apple. The PackageMaker docs are abysmal BTW. I would fire whomever wrote them. I agree that Apple doesn't invest enough in our documentation. That's been noticed and there should be some visible improvement in the next 12 months. Maybe if Apple included a simple feature such as this in PackageMaker, we wouldn't even be wasting our time on this discussion Don't blame me - I have to work around your laziness. What's the radar # for your enhancement request? The bug wasn't obvious among the more than a thousand I'm tracking. Peter Bierman wrote: At 5:18 PM -0700 4/26/07, Mike wrote: My guess is in Installer.app when "Restart" is clicked it just quits Installer and everything goes away. It probably ignores any errors if the bundle from a pkg can't be closed or it may in fact have already closed the pkg when the Restart pane is displayed. Don't guess. You've got two of Apple's installer engineers telling you not to rely on that behavior. You won't get much sympathy if you do it anyway and it breaks in the future. -pmb This email sent to site_archiver(a)lists.apple.com

1 0

The common way to license/protect a commercial software
by Filippo Ignozza 27 Apr '07

27 Apr '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Organization: Digital Video S.p.a. Priority: normal _______________________________________________ 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: Get the package's NSBundle from a plugin
by David Bainbridge 27 Apr '07

27 Apr '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Apr 26, 2007, at 7:42 PM, Mike wrote: OR Don't blame me - I have to work around your laziness. Mike _______________________________________________ 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 at least appreciate the time they take to answer questions on this list. Such comments are not constructive nor appropriate. If it breaks in the future I will re-write it as I usually end up re-writing things anyway to work around Apple's lack of features and lack of documentation. Or maybe if the Installer/Packagemaker docs actually *mentioned* when Installer closes the package, that would be helpful in making this decision also. But that's too much to expect from a 'world- class' company such as Apple. The PackageMaker docs are abysmal BTW. I would fire whomever wrote them. Maybe if Apple included a simple feature such as this in PackageMaker, we wouldn't even be wasting our time on this discussion. How hard would it be for Installer.app and PackageMaker's engineers to include a single checkbox in PackageMaker named "Delete package after intsall"? Since the Installer is the one who does the package manipulation, only it knows when it is safe to move/delete a package. Peter Bierman wrote: At 5:18 PM -0700 4/26/07, Mike wrote: My guess is in Installer.app when "Restart" is clicked it just quits Installer and everything goes away. It probably ignores any errors if the bundle from a pkg can't be closed or it may in fact have already closed the pkg when the Restart pane is displayed. Don't guess. You've got two of Apple's installer engineers telling you not to rely on that behavior. You won't get much sympathy if you do it anyway and it breaks in the future. -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/dbainbridge% 40mac.com This email sent to dbainbridge(a)mac.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Get the package's NSBundle from a plugin
by Mike 27 Apr '07

27 Apr '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.0 (Macintosh/20070326) OR Don't blame me - I have to work around your laziness. Mike -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.… If it breaks in the future I will re-write it as I usually end up re-writing things anyway to work around Apple's lack of features and lack of documentation. Or maybe if the Installer/Packagemaker docs actually *mentioned* when Installer closes the package, that would be helpful in making this decision also. But that's too much to expect from a 'world-class' company such as Apple. The PackageMaker docs are abysmal BTW. I would fire whomever wrote them. Maybe if Apple included a simple feature such as this in PackageMaker, we wouldn't even be wasting our time on this discussion. How hard would it be for Installer.app and PackageMaker's engineers to include a single checkbox in PackageMaker named "Delete package after intsall"? Since the Installer is the one who does the package manipulation, only it knows when it is safe to move/delete a package. Peter Bierman wrote: At 5:18 PM -0700 4/26/07, Mike wrote: My guess is in Installer.app when "Restart" is clicked it just quits Installer and everything goes away. It probably ignores any errors if the bundle from a pkg can't be closed or it may in fact have already closed the pkg when the Restart pane is displayed. Don't guess. You've got two of Apple's installer engineers telling you not to rely on that behavior. You won't get much sympathy if you do it anyway and it breaks in the future. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Get the package's NSBundle from a plugin
by Peter Bierman 27 Apr '07

27 Apr '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com -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 5:18 PM -0700 4/26/07, Mike wrote: My guess is in Installer.app when "Restart" is clicked it just quits Installer and everything goes away. It probably ignores any errors if the bundle from a pkg can't be closed or it may in fact have already closed the pkg when the Restart pane is displayed. Don't guess. You've got two of Apple's installer engineers telling you not to rely on that behavior. You won't get much sympathy if you do it anyway and it breaks in the future. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Get the package's NSBundle from a plugin
by Mike 27 Apr '07

27 Apr '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.0 (Macintosh/20070326) Thanks, Mike Hi Mike, On Apr 26, 2007, at 3:05 PM, Mike wrote: Just some food for thought... - Luke Mike I've used you suggestion and done: mpkgBundle = [ NSBundle bundleForClass:[ DeletePane class ] ]; DeletePane being my subclass to the InstallerPlugin class. Why wouldn't it work (if you replace Class with class)? On Apr 13, 2007, at 5:02 AM, Mike wrote: Thanks, Mike _______________________________________________ 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/luke%40apple.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.… Yeah, it could be done that way too. In fact that is the way our old product did it - look for a flag in the prefs file after reboot and if true, then blow away the installer. The path could also be saved in the prefs file at install time and then the product could read that to learn where the installer was and blow it away. My guess is in Installer.app when "Restart" is clicked it just quits Installer and everything goes away. It probably ignores any errors if the bundle from a pkg can't be closed or it may in fact have already closed the pkg when the Restart pane is displayed. Putting a symlink in /tmp wouldn't work in this case incidentally because our installer requires reboot and the OS blows away everything in /tmp after each reboot. Luke Bellandi wrote: I verified that in all cases (that I know of), moving the .pkg or .mpkg to /tmp from within a plugin does work and does not crash the installer, but only on two conditons: 1) that the moving of the package happen as the very last thing before the final "Restart" button is clicked and 2) that the pkg or mpkg *requires* the Restart option. Under these conditions, I find that moving the package to tmp as the last step works fine. Just to play devil's advocate, that is not a supported use-case, even though you've found it to work empirically for now. A file/bundle is expected to exist for as long as it is open by a process. There is no guarantee that the Installer is done with a package until its process is dead. A solution that doesn't break that contract would be to write a lightweight sentinel tool that you spawn after your install has completed. This tool can run in the background and wait until there are no processes with bundle ID 'com.apple.installer' running, or until it receives a system shutdown message, at which point it can delete the package and quit itself. How will it know where the package is? If your plugin makes a symlink with a known name in /tmp/ to the package's location on disk, your sentinel tool can look for that file and delete the file its symlink points to (as well as the symlink.) The only way this could fail is if a user hard-rebooted her machine and your sentinel tool didn't have a chance to do its duty. Peter Bierman wrote: Yes, except I don't see any reason for you to instantiate an NSBundle for the .mpkg itself. You just need the path, so you can rename(2) it into the /tmp directory. But removing or moving the package while the installer is still using it is probably not going to go smoothly. It'll probably cause a crash at some point. You'd be better off having your app remove the package when launched. In the meantime, please file an enhancement request in Radar for a flag causing us to delete the package for you when the installer is done with it. -pmb At 3:54 PM -0700 4/13/07, Mike wrote: So what you are saying is to get the path to the plugin's bundle, then manually munge it to get the full path to the containing .mpkg, then use bundleWithPath to make a new NSBundle to the .mpkg itself? I am assuming the upshot here is that I have to do some path manipulation myself in order to get at the .mpkg's bundle and that there is no way to get it directly with any NSBundle call from within the plugin. This does indeed give me the bundle to my plugin so if the manual path munging is the way to go, then this will work. Stéphane Sudre wrote: You probably have at least one subclass of the Installer Plugins classes. If you run this method on an instance of this subclass, you will get the NSBundle of the plugin. Then you would just have to build the path of the metapackage "bundle" from the path of the plugin bundle (+[NSBundle bundleWithPath:]). That would be a neat trick but in this case it won't work because self is an InstallerPane which is a member of an InstallerSection which is an NSView in the class object. Peter Bierman wrote: At 6:01 PM -0700 4/12/07, Mike wrote: Is there an easy way to get the NSBundle of the .mpkg that contains a plugin from the plugin's code? I see the InstallerSection class has a -bundle method but it appears to return the plugin's bundle, not the bundle of the .mpkg itself. This also doesn't seem to be mentioned in Software Delivery Guide. A useful NSBundle trick for plugins everywhere: [NSBundle bundleForClass:[self Class]] This should find you the bundle that whatever class you're in came from. -pmb This email sent to luke(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Get the package's NSBundle from a plugin
by Luke Bellandi 26 Apr '07

26 Apr '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Hi Mike, On Apr 26, 2007, at 3:05 PM, Mike wrote: Just some food for thought... - Luke Mike I've used you suggestion and done: mpkgBundle = [ NSBundle bundleForClass:[ DeletePane class ] ]; DeletePane being my subclass to the InstallerPlugin class. Why wouldn't it work (if you replace Class with class)? On Apr 13, 2007, at 5:02 AM, Mike wrote: Thanks, Mike _______________________________________________ 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/luke%40apple.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 verified that in all cases (that I know of), moving the .pkg or .mpkg to /tmp from within a plugin does work and does not crash the installer, but only on two conditons: 1) that the moving of the package happen as the very last thing before the final "Restart" button is clicked and 2) that the pkg or mpkg *requires* the Restart option. Under these conditions, I find that moving the package to tmp as the last step works fine. Just to play devil's advocate, that is not a supported use-case, even though you've found it to work empirically for now. A file/bundle is expected to exist for as long as it is open by a process. There is no guarantee that the Installer is done with a package until its process is dead. A solution that doesn't break that contract would be to write a lightweight sentinel tool that you spawn after your install has completed. This tool can run in the background and wait until there are no processes with bundle ID 'com.apple.installer' running, or until it receives a system shutdown message, at which point it can delete the package and quit itself. How will it know where the package is? If your plugin makes a symlink with a known name in /tmp/ to the package's location on disk, your sentinel tool can look for that file and delete the file its symlink points to (as well as the symlink.) The only way this could fail is if a user hard-rebooted her machine and your sentinel tool didn't have a chance to do its duty. Peter Bierman wrote: Yes, except I don't see any reason for you to instantiate an NSBundle for the .mpkg itself. You just need the path, so you can rename(2) it into the /tmp directory. But removing or moving the package while the installer is still using it is probably not going to go smoothly. It'll probably cause a crash at some point. You'd be better off having your app remove the package when launched. In the meantime, please file an enhancement request in Radar for a flag causing us to delete the package for you when the installer is done with it. -pmb At 3:54 PM -0700 4/13/07, Mike wrote: So what you are saying is to get the path to the plugin's bundle, then manually munge it to get the full path to the containing .mpkg, then use bundleWithPath to make a new NSBundle to the .mpkg itself? I am assuming the upshot here is that I have to do some path manipulation myself in order to get at the .mpkg's bundle and that there is no way to get it directly with any NSBundle call from within the plugin. This does indeed give me the bundle to my plugin so if the manual path munging is the way to go, then this will work. Stéphane Sudre wrote: You probably have at least one subclass of the Installer Plugins classes. If you run this method on an instance of this subclass, you will get the NSBundle of the plugin. Then you would just have to build the path of the metapackage "bundle" from the path of the plugin bundle (+[NSBundle bundleWithPath:]). That would be a neat trick but in this case it won't work because self is an InstallerPane which is a member of an InstallerSection which is an NSView in the class object. Peter Bierman wrote: At 6:01 PM -0700 4/12/07, Mike wrote: Is there an easy way to get the NSBundle of the .mpkg that contains a plugin from the plugin's code? I see the InstallerSection class has a -bundle method but it appears to return the plugin's bundle, not the bundle of the .mpkg itself. This also doesn't seem to be mentioned in Software Delivery Guide. A useful NSBundle trick for plugins everywhere: [NSBundle bundleForClass:[self Class]] This should find you the bundle that whatever class you're in came from. -pmb This email sent to luke(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0