- This topic has 11 replies, 7 voices, and was last updated 16 years, 6 months ago by
mosen.
-
AuthorPosts
-
September 4, 2008 at 8:07 am #373978
mosen
ParticipantHiya Guys,
I already posted something like this in Projects but I thought I’d let you know anyway…
Since it seems likely that Adobe will never release a .pkg formatted CS3 Installer I have begun to write a repacker. The repacker acts like a replacement for Setup.app and emulates the platform dependent functions provided by Setup and associated frameworks.
Currently the repacker will parse a CS3 deployment file and create a series of dependencies. It will also unpack a payload and install into a desired folder (I use my own faux root). There’s still a long way to go before it can produce a fully working install.
The product configuration and registration database commands (nothing to do with licensing) will be converted into postflight scripts.
The outcome of this is that we can have a system of generating an mpkg from retail media.. and that each individual .pkg component will represent exactly one adobe payload. The bonus is that individual package selection will produce exactly the same result as if you had selected the component in the retail installer.
This is a bit of a monster task so I will be working on it on and off.. but i’ll keep you guys updated.
September 4, 2008 at 2:36 pm #373982gsprague
ParticipantTry this link, it is working well for me with one exception, I am using iceBerg rather than PackageMaker:
http://blog.irisink.com/?p=106September 12, 2008 at 6:56 pm #374080typofonic
ParticipantMosen,
That’s great to hear. That could be really useful for a of people!
Please keep us updated on it!
October 1, 2008 at 1:24 am #374302mosen
ParticipantJust an update on the progress…
How it works:
– The repacker parses the payload structure and generates an index.
– The test script is set up to install a named payload for eg. “Dreamweaver”
– The payload manager finds all dependencies and satisfies those dependencies before installing the requested payload.
– Each dependency and payload is installed inside its own package root folder, named after the payload. I.e “AdobeDreamweaver9en_US” contains /Applications and /Library
– Running the application from the payload folder generates a licensing error (easy to fix with a 1 line text change – this will be scripted).
– After the licensing error is fixed the application runs perfectly assuming all of the “Common” components are already available.99% of the payload installers are parsed perfectly. With the exception of the flash plugin (because of some funky browser plugin detection) and two other items in “Common”.
The uninstaller scripts are not yet handled, so the repacker generated packages won’t generate uninstallable apps at the moment.
The CAPS/PCD database entries are not generated into the postflight scripts, so effectively my repacker packages are still broken and useless 🙂 However, I am very very close to a workable system of generating .pkg’s from adobe payloads! yay
Note about CS4: We haven’t purchased CS4 yet so I don’t know how that will work.. I’d be willing to bet that they use exactly the same build system for CS4 because throwing out the platform independent build process used in CS3 that they just made, would be like throwing away money.
Mosen.
October 4, 2008 at 7:19 pm #374364jasonpgignac
ParticipantActually, and this is second hand info, but I’ve been told that CS4 will have a repackager downloadable from Adobe, that will allow you to wrap the installers in a PKG. I can’t confirm that, though.
October 5, 2008 at 12:59 am #374366blake
ParticipantI can ask around but I’m fairly doubtful that Adobe is working on any .pkg based installers or repackagers. The only thing I have heard of is taking the CS installers and putting them in a .pkg. This pkg simply is a folder that starts the adobe unattended network installer. This was just a tech note or recommendation from support. This works for ARD installations but not instadmg..
Blake
October 7, 2008 at 3:59 pm #374385blake
ParticipantHere are the details for the CS4 deployment tools.
http://www.adobe.com/aboutadobe/openoptions/cs/deployment_toolkit.htmlBlake
October 8, 2008 at 4:43 am #374396mosen
Participantlooks like the CS4 deployment tools will just be a custom way to deploy the apps as an all-in-one installer. Still won’t support InstaDMG,
from the website:[quote]
Can I create packages that are compatible with MSI and PKG installs?No. Because of the complexity of the Creative Suite installation process, Adobe has created custom installers to ensure the correct installation of the software and their shared components.
[/quote]I’ll keep working on this… Even if it takes a while 🙂
Mosen.
October 10, 2008 at 12:09 am #374423larkost
ParticipantThe CS4 installer looks to be only a small change from the CS3 one. You can create a couple of files that will allow installer to run in automated mode (where the license files are put in for you, and you can kill the auto-updates). The only change I have seen in the docs from CS3 is that you don’t have to fish out the files from /Library/Application Support. It still does not disable Acrobat self-heal.
October 11, 2008 at 1:02 pm #374432jasonpgignac
ParticipantMy bad, sorry to get everyone excited – I should have known better than to believe Adobe was doing something the standard way 😉
October 15, 2008 at 9:59 am #374452alantrewartha
Participanti don’t want to get hopes up, but i was at an extensis/apple event yesterday (london uk) where there was some muttering about adobe coming up with a ‘proper’ deployment strategy in the v near future.
i didn’t press anyone on this, but it sounded hopeful.
October 16, 2008 at 11:46 pm #374469mosen
ParticipantI’m thinking that they won’t give up their current deployment strategy, why?
because it works cross-platform, and they only need one set of scripts to do the windows installer and the
osx installer.If they change to .pkg/.msi or something then they just lose a whole lot of time duplicating the installer code.
Mosen.
-
AuthorPosts
- You must be logged in to reply to this topic.
Comments are closed