Hi Alok, I admit to now knowing the inner-workings of DC, but I would be wary for splitting things into to many parts unnecessarily.
I'm not sure about the fact that you won't be able to call transfer directly - at least I seem to remember, from various discussions, that there was mention of being able to specify transfer checkpoints in the XML Manifest - e.g. running CPIO or IPS transfers with varied arguments - thus allowing users to install additional packages, or files. Is this not the case? Thanks, Darren. On 05/26/10 11:13 PM, Alok Aggarwal wrote: > There are a number of existing DC finalizer scripts > that call target instantiation and transfer at > various points in time. > > As these finalizers get converted over to being CUD > Checkpoints, I don't believe they can call target > instantiation/transfer directly in CUD any more. Instead, > a Checkpoint that needs to call TI/Transfer would > need to be broken up into multiple different checkpoints > where TI/Transfer is one of them. > > So, for example, with boot_archive_archive.py, it > would more or less get distilled into the following > distinct checkpoints - > > 1) Compute various boot_archive properties - size, pad, > nbpi, etc > 2) Instantiate the boot_archive target > 3) Do optional post-processing on that boot_archive in > case of sparc > 4) Transfer the contents into boot_archive > 5) Release the resources setup in (b) > 6) Compress the boot_archive > > Each of these checkpoints will store data needed by any > other checkpoints in the DOC as they go along. > > Does anyone disagree with this? > > Thanks, > Alok > _______________________________________________ > caiman-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
