On 07/13/10 11:02 AM, jean.mccormack wrote:
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?
Let me look at the email thread on this. Do you remember what the dates
were of this discussion? I suppose the app could give you this data but
it isn't clear to me why this would be an issue. The image options are
very limited so from that perspective there isn't a lot of data that is
being translated in the checkpoint.
yes, we should chat but I want to review the thread on this to try to
understand what the issues were. I vaguely recall but I think that this
had to do with the checkpoint interfaces exposed more than the
translation of the image options within the checkpoint.
thanks,
sarah
****
Jean
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
