On 07/12/10 07:52 AM, Sarah Jelinek wrote:
On 07/ 9/10 02:06 PM, [email protected] wrote:
On 07/ 9/10 12:11 PM, Alok Aggarwal wrote:
Jean: See below for a transfer related comment.
On Fri, 9 Jul 2010, Sarah Jelinek wrote:
On 07/ 8/10 07:24 PM, Alok Aggarwal wrote:
Hi Sarah,
A few things that still need to be changed -
a) GRUB menu customization section from dc_spec.
I do realize that GRUB2 is going to change
some things in this area but still we need a
way to specify custom grub menu entries.
I actually deliberately didn't include these in the schema. I
thought that perhaps this was better done as an argument or set of
arguments to the appropriate checkpoint. Does this seem like it
would work for DC?
We could do it as arguments but I think readability would
take a hit in doing that.
Considering that multiple GRUB menu entries can be specified
and each of them span multiple lines, it could get somewhat
complicated.
b) iso sort file specification from the dc_spec
ok, will add.
c) dc_instance should have an additional attribute
along the lines of "incremental_media(true|false)"
to support fixing defect 6794
I have this in the latest dc.dtd. I haven't pushed it yet, but it
is there.
d) Are primary_source/secondary_source in the dc_spec
the equivalent of the current post_install_repo_default_authority
and addl_authority?
yes...these are post install definitions. I have renamed this
though in response to Dave's comments on these. But, the use of
them in DC remains as a post install repo setting.
If so, I think it would be better to abstract
these out as a software_spec section. The reason
for this is - DC is going to leverage the transfer
module to set the ips attributes. So, even if it
is specified in the dc_spec section, DC internally
will have to instantiate the appropriate Transfer
class, retrieve the ips attributes from the dc_spec
section and set them in the Transfer object.
Seems like it woul be just be simpler to abstract them
out as a software_spec action.
It is a software_spec element. I am not sure what you mean by
making it a software_spec attribute. Can you clarify?
What I'm proposing is - let's take the post_install_rep
and addl_authority out of the dc_spec section for the
above reasons.
Instead, encapsulate it as -
<software_spec name="set_ips_attributes">
<primary_source>
<publisher name="xxx">
<origin name="yyy"></origin>
<pub_mirror name="zzz"></pub_mirror>
</publisher>
</primary_source>
<secondary_source>
<publisher name="aaa">
<origin name="bbb"></origin>
</publisher>
</secondary_source>
<software action="noinstall" type="ips">
</software>
</software_spec>
Could something like this be done?
I believe that's what the spec has. I wrote up some other thoughts on
this but forgot to send them. You should see that message soon.
e) Where do IPS attributes such as, say, generate_ips_search_index,
get specified in the DC manifest?
Good question.. I would think that they would be in the
software_spec, image element as an attribute on that. Would this work?
That should work. Jean, do you agree?
I think so. Might also be a good place to put the cpio args if decide
to put them in here.
Can someone give me an example of what they are thinking it would
look like?
It would look something like this:
<software_spec>
<destination>
<image ips_search_index="true">
</destination>
<software>
...
</software>
<software_spec>
The idea is that the generation of the ips search index is an
attribute on the IPS image we are creating as part of the DC process.
I believe that should work. Thanks
Jean
thanks,
sarah
*****
Jean
Another thing I forgot to mention is that - for sparc
images, we need a section that indicates which files
shouldn't be fiocompress'd. I didn't notice such an entity
in the schema. Could it be added?
Thanks,
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
