On 07/13/10 10:49 AM, Sarah Jelinek wrote:
On 07/13/10 09:40 AM, jean.mccormack wrote:
On 07/13/10 07:04 AM, Sarah Jelinek wrote:
Hi Jean,
Sorry, after really looking at this I need the ips/cpio
arguments to fall under software, reason being that these
arguments can and often will change within a checkpoint but
different transfers within. Best served by an example....
In a checkpoint I really want to transfer via cpio files from:
/usr/bin with default cpio args
/usr/lib with cpio args "-pdm"
/usr/whatever with default cpio args.
Are these args something the user should have control over? Are
these set in the application?
Possibly? But ips_search_index also falls into the category of I
would like it under software. All the IPS ones do.
In fact, you have 3 types of IPS argument lists, one for creation
of the image, one for pkg installing and one for
pkg uninstalling. So if a checkpoint does a image
create/install/uninstall that is 1 software_spec node but 3
software nodes.
yes, you are correct. But, in the case of 'create' the 'install'
action will create the image, using the image attributes if one is
not created, right?
Well the reality is that the arguments to image_create,
plan_install and plan_uninstall are very different. So if I have a
set of arguments without specifying which one they go to how do I
know which call to send them to? If I send a argument
specifications to plan_install that include args not valid for
plan_install (meant for create) the call will barf.
So, I am not clear what the arguments to create, plan_install and
plan_uninstall have to do with setting the image attributes. If you
look at the set of pkg command for the three, create, install,
uninstall the args are:
I see now why we're at odds, you're talking much higher level than I am.
So who will be responsible for taking those image attributes and
giving me the ips api args that correspond to them so I do the right
thing? I assume the app?
No... the checkpoint will manage this. The manifest parser will put
these in the DOC via a software object and as part of the software
object that matches the checkpoint(via naming) you ask for this data
and translate it as required for the api calls.
Does this make sense?
thanks,
sarah
We have an issue here then. That was part of my original design spec and
it was shot down big time. Maybe we should talk on the phone at some point?
Jean
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
