Hi Alok,
This is an interesting proposal, but I have a few questions/suggestions.
My main thought is that I think XInclude would be more suitable
here. You would move the entire <software_data> section to a new
XML file, eg; /path/to/boot_archive_contents/file.xml would just contain:
<software_data action="install" type="FILE">
<name>usr/bin/nawk</name>
...long list of <name> elements goes here...
<name>var/yp/nicknames</name>
</software_data>
And the main manifest file would look something like:
<software xmlns:xi="http://www.w3.org/2001/XInclude";>
<xi:include href="/path/to/boot_archive_contents/file.xml"/>
</software>
(Or you could just have the <name> elements in the xincluded file?)
This would still require a small adjustment to the schema, but would
achieve the benefits of simplifying the main manifest file for users
and allowing common lists of files to be re-used by different manifests.
A few more questions about your original proposal:
Is /path/to/boot_archive_contents/file an XML file or purely
a text file listing one file per line?
What about the current DIR section for directories - would you
provide a similar "DIRPATH" type for that?
Also, what about the small differences you note between the different
slim_cd/text/ai manifests? Are you saying they can be merged into
one common file, or would you have different
/path/to/boot_archive_contents/file files for each?
The existing software.dtd schema does not allow for the <software_data>
element to have text (the "/path/to.." bit in your example), so it would
make more sense to put the path in a <name> sub-element, eg:
<software_data action="install" type="FILEPATH">
<name>/path/to/boot_archive_contents/file</name>
</software_data>
- Dermot
On 09/08/10 23:24, 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.
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
