On 11/22/10 01:32 PM, [email protected] wrote:
In the CUD design meeting we recently discussed a modification to the
software.dtd with respect to the type attribute.
The current software dtd is defined as this (relevant section only):
<!ELEMENT software (destination?, source*, software_data*)>
<!ATTLIST software name CDATA #IMPLIED>
<!ELEMENT software_data (name*)>
<!ATTLIST software_data action (install|uninstall|unpack|noinstall)
"install">
<!ATTLIST software_data type
(IPS|SVR4|ARCHIVE|IMAGE|P5I|DU|P5P|FILE|DIR) "IPS">
<!ELEMENT name (#PCDATA)>
Which means that the manifest looks something like this:
<software name="transfer-ips-install">
<destination>
<image img_root="/rpool/new_dc_test/build_data/pkg_image" action="create">
<img_type completeness="full"></img_type>
<property val="true">flush-content-cache-on-success</property>
</image>
</destination>
<source>
<publisher name="opensolaris.org">
<origin name="http://ipkg.sfbay/dev";></origin>
</publisher>
</source>
<software_data action="install" type="IPS">
<name>SUNWcs</name>
<name>SUNWcsd</name>
<name>entire</name>
</software_data>
<software_data action="install" type="IPS">
<name>slim_install</name>
<name>system/install/media/internal</name>
</software_data>
<software_data action="uninstall" type="IPS">
<name>slim_install</name>
</software_data>
</software>
The desired change is to modify the dtd to move the type field from
software_data to software.
Because CPIO does need some type of indication of whether the data is a
file or directory, it will need a data_type attribute which is valid per
software_data node. That attribute will not be required or even relevant
for any other type of transfer.
Maybe I've asked this before, but is there really no way that CPIO can
be smart enough to figure this out for itself, at least in most cases if
not all?
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
