On 09/13/10 04:21 PM, Jack Schwartz wrote:
Hi Alok.
Hopefully I'm not too late on this issue. I'm just back from vacation...
I also like Dave's idea of tagging boot_archive files in packages.
Most of the time, as you say, users won't need to make additions to
this list.
If additional files are desired, I would think the list of additions
would be small enough to just keep it in the manifest itself. This
removes the complication of having a separate file for it.
Would there be a need to replace some "factory" files taken from
packages, with custom versions, for debugging or development
purposes? If so, how would this work? Start with the package
versions, and then overlay the custom files?
This could easily be done in a customized transfer checkpoint that would
transfer the custom version from whereever to the boot archive.
Also, would there ever be a need to not-include a file which is tagged
in a package, for debugging or development purposes? Would this be
considered too corner-case?
Again you could customize the transfer to put these files in the exclude
list. Easily done.
Jean
My $.02,
Jack
On 09/ 9/10 12:00 PM, Alok Aggarwal wrote:
On Thu, 9 Sep 2010, Karen Tung wrote:
I really like this idea too, but got a couple questions/comments:
* Since different images types needs a few specialized things in the
root archive
for booting the image in addition to the "common" list of things,
would we need to
tag items by image type? Or we have the "common root archive" tag
which most
root archive contents would belong, and then, have image specific
tags for the few
things that differs between the image types.
The boot_archive isn't very different across the
various media types with the differences being:
http://cr.opensolaris.org/~aalok/slim.vs.text
http://cr.opensolaris.org/~aalok/slim.vs.ai
As you can see we can normalize the contents to
be the same across the media types without much
impact on the boot_archive size.
* Since groups outside of the install team might or might not be
familiar with
how all the different images and installers work, we would need a
way to
review what new items are added to the root archive to prevent it from
getting too big. We also need a way to easily tell what gets
removed from
the root archive, in case that removal breaks things.
As Dave pointed out earlier, this is the main issue
that needs to be worked out with tagging the boot_archive
contents in some way in pkg(5). We need to work out an
overall architecture wrt how the boot_archive contents
are going to be maintained and evolved over time; and
also provide guidelines to the broader Solaris community
on what comprises a boot_archive.
Since this is more of an architectural issue and not
necessarily specific to DC, I am leaning towards not
pursuing it as part of the DC/CUD project.
Instead, for ease of maintainability I'm going to go
with the xinclude approach that Dermot outlined earlier till the time
we come up with the pkg tagging.
Thanks,
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
