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"...
Thanks,
Darren.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
