I’m doing the package creation part of InstaDMG now.
Wanted to get people’s thoughts on Creative Suite and Creative Suite *updates* deployment, specifically.
Via the logGen, pkgGen, Package Maker route I’ve made packages for CS3 Design Premium (minus Flash and Dreamweaver b/c we don’t do much interactive media) & all updates current to, well, today.
The update package brings cause for concern.
It’s huge, logGen found files to remove, and I wonder how realistic it is to expect to update it frequently.
Have people played with packaging this app and the updates at all?
In general, for file removal, I’m thinking a preinstall script in the package will work. What do people think?
Disclaimer: We’re using FileWave to manage the installation of third-party software, so I really haven’t thought through building installation pkgs.
Exactly how are you planning on doing the installation? Are you looking to place CS3 into your “standard” ASR DMG, or are you looking to run the CS3 install as a post-install?
And for each of those, are you planning to either step through the base Adobe installer + Adobe updates, or are you going to roll your own installation pkg? Are you going to use the package to “update” existing installations of CS3?
Sounds good. You might want to consider splitting the package into each of the component applications (Photoshop, InDesign, etc) and the support files (stuff in /Library) and making a mpkg to tie it all together. Depends on how well your package-generation program handles the 5.2GB CS3 package.
You could repackage it where the pkg dumps the install files in a temp location and then the postscript runs the installer silently and then cleans it up. This may not be as efficient, but it would work very cleanly.
I had thought (incorrectly from the looks of it) that if the Diff file was fed in, that it would record the file removal needs, and that pkgMaker would send that info along to PackageMaker…is that incorrect?
Can you detail the postflight scripting tasks necessary?
[QUOTE][u]Quote by: Patrick+Fergus[/u][p]Disclaimer: We’re using FileWave to manage the installation of third-party software, so I really haven’t thought through building installation pkgs.[/p][/QUOTE]
I think Patrick could have included this link:
[url]http://filewave.org/viewtopic.php?t=643&sid=e415e6e1e176f751dfc9d99ba1232a76[/url]
But actually, [url]http://filewave.org/[/url] have a lot of great whitepapers on how to build packages for certain software, and it’s easy to follow, even if we are building an Apple Installer package.
I’m having permissions problems (I think) trying to package CS3 Design Premium.
So far, I’ve tried using InstallEase and logGen/pkgGen/PackageMaker (based on this article http://blog.irisink.com/?p=106), both on Leopard.
With the logGen/pkgGen/PackageMaker route, I get an error at the end of building “Could not write the permission directory hierarchy” (and about 1900 warnings) but I’m not experienced enough with PackageMaker to interpret this. (Also, when I tried “Apply Recommendations”, the warnings go away, but not the error.)
InstallEase (using the automatic/snapshot based method of package building) gets a POSIX error about 15 minutes into building the package.
I’m going to jump out on a limb and ask what may be a naïve question: with applications that have a “silent install” like CS3, could we just install it onto the open disk image before it is compressed for ASR? I understand that this would require a change in InstaDMG, but it seems like a natural fit. Is there a technical limitation that I am unaware of? I’m not sure package making is the best solution here.
There is an issue with Leopard’s version of Developer Tools which has been noted on other afp548 threads. I’ve been able to generate smaller packages but not Office 2008 or Adobe CS3 Design Premium pakcages. Others have reported having this issue as well. This problem affects PackageMaker and InstallEase as both use use Developer Tools to build the packages. Whereas Tiger’s Developer Tools has no difficulty generating Office or CS3 packages. Check out the “Leopard PackageMaker Issues” thread for more information
…..as to whether creating custom packages is the best solution? For me it is. The packages I’ve been testing install much more quickly then installing using Adobe’s install mechanism. The Adobe base CS3 installer is very inefficient. Adobe’s CS3 installer copies each file individually, then checks the proper GID and UID for the path to the file, and sets it. One at a time. My custom CS3 installer takes close to 5 minutes to install on a MBP laptop. Adobe’s takes about 21 minutes (from a disk image of the install DVD). Installing all the custom packages of my InstaDMG build train takes 19 minutes total. Of which, I estimate, CS3 and CS3 updates take about 13 minutes. Compared to approximately 1.5 hours for CS3 + updates using Adobe’s installer and updater mechanism.
I am employed at an educational institution and am primarily interested in building images for Mac computer labs. But I do perform the occasional “one off” CS3 install for staff members. Being able to perform a CS3 install plus updates in under 15 minutes is a great boon. Your needs will no doubt vary.
If you do go the custom installer package route, I would suggest the following:
1. Create a package for the CS3 bundle excluding updates. I should add that we install the full CS3 Design Premium bundle in all labs so I don’t have to worry about installing portions of CS3 bundles here. Having said that it shouldn’t be difficult to break the bundle down into its component applications.
2. Launch Adobe Updater and make note of the updates listed. Install each update one at a time and generate a package for each update. Use Adobe Updater to verify that you have installed all Adobe updates. Optional: Bundle up all the Adobe updates in a metapackage. This is what I do.
Final comment: Keeping everything in individual packages makes for a modular and very flexible build process. It’s relativeley easy to add new Adobe updates that come down the pike. One last note. Adobe has discontinued Adobe Stock Photos. Adobe provides a special uninstaller which uninstalls the Bridge plugin but it doesn’t delete the Stock Photos folder. If you create a package to delete Stock Photos (and the Stock Photos directory) make sure you install it after all the Adobe updates have been installed. Some of the updates will recreate the Stock Photos directory.
Comments are closed