I really like that idea since it puts the onus on the owners of the files to make the decision on what's included it not.
Darren "Dave Miner" <[email protected]> wrote: >On 09/ 8/10 06:24 PM, Alok Aggarwal wrote: >> The DC manifests for the various x86 media types currently >> have a section for boot_archive_contents that defines >> what gets included in the x86 boot_archive. >> >> Each of these manifests (slim_cd_x86.xml, all_lang_slim_cd_x86.xml, >> text_mode_x86.xml and ai_x86_image.xml) has a such a section. >> The contents of this section are more or less the same across >> these manifests[1]. >> >> As we're re-writing DC[2], it make sense to re-evaluate whether >> the boot_archive_contents can be factored out into a common file >> that can then be referenced in each of the various manifests. >> > >Another avenue to explore is to not have this list at all in the >manifest; instead, tag those objects in the packages as they're >published by the consolidations with some appropriate attribute. Then >DC's checkpoint that constructs the boot archive could just use pkg >search to compile the list of files and directories to transfer. > >Dave > > >> The advantages of factoring out the boot_archive_contents >> would be: >> >> a) It would make the management of the boot_archive contents much >> easier across the various media types. Any time there's a change >> to the contents, it can be done in a single place instead of >> in every manifest. >> >> b) The boot_archive_contents is likely to not be touched by the >> users of DC in 80% of the cases. Extracting out the boot_archive >> contents list like this just helps readability of the manifest >> for those 80% of the users. >> >> One way of doing it would be to have another software_data 'type' - >> say, FILEPATH. The section of the manifest would look like: >> >> <software_data action="install" type="FILEPATH"> >> /path/to/boot_archive_contents/file >> </software_data> >> >> Transfer would just look at the 'FILEPATH' and try to transfer >> everything contained within "/path/to/boot_archive_contents/file". >> >> Would there be issues wrt refactoring the manifests like this? >> >> Alok >> >> [1] http://cr.opensolaris.org/~aalok/slim.vs.text >> http://cr.opensolaris.org/~aalok/slim.vs.ai >> >> [2] http://hub.opensolaris.org/bin/view/Project+caiman/DC+to+CUD+Migration >> _______________________________________________ >> 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 _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
