On 03/21/12 11:42, Darren Kenny wrote:
On 21/03/2012 18:02, Ethan Quach wrote: 8< SNIP 8<My only tiff here is the implied implementation. I not sure I agree that "reject" should be an action type. From a logical standpoint, it would apply to some other peer elements, but not others. To me, that's confusing; and as a general solution to handle options, doesn't scale. Thinking out loud, could we implement this by introducing an<option> element (like the one defined in target.dtd.1) as a subelement of <software_data type="install"> ? i.e. <software name="foo_IPS"> <software_data action="install"> <name>pkg:/entire@latest</name> <name>pkg:/group/system/solaris-large-server</name> <option name="reject" value="pkg_to_reject"/> <option name="reject" value="another_pkg_to_reject"/> </software_data> </software> The transfer/ips module would semantically take options we explicitly want, and ignore and not pass through all others (even ones that might be valid to pkg.) We'd perhaps just log what we're ignoring. The big benefit with this in that we can later decide to support any other options we might want (perhaps new ones) by updating the installer transfer/ips implementation, but the dtd doesn't have to change. The downside is loose syntax, but I personally can live with that.I can certainly see where you're coming from, and what you're suggesting could work without an incompatible change to the DTD now... My own feelings are that having multiple<options> with the same name is just as confusing and not at all obvious that it would be allowed - there is also no code-reuse possible here, but that's another story. I'm still very comfortable with the use of an action="reject", which I feel still reads just fine, TBH and is not a huge leap in even documentation terms. If you still feel that is not a good solution, another possibility is to add a<reject> tag which would look like: <software> <software_data action="install> <name>...</name> <name>...</name> <reject>...</reject> <reject>...</reject> </software_data> </software> Which would only semantically be permitted when action="install". Again, this would be a compatible change, and not have any negative impact on existing consumers. But I honestly don't think it's much of a gain over the use of the action="reject"...
In pkg semantics, with "reject" being an option to an "install" operation, I think defining it somewhere within the software_data action="install" would be more consistent, so between your two, I like the later better.
-ethan
Thanks, Darren.
_______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
