Antonello Cruz wrote: > The case looks good. > > I have 2 questions: > 1 - When would someone want to import manifests with SVCCFG_CHECKHASH > unset? what is the purpose of the option? > BTW, shouldn't this new (?) env variable be in the interface table? > There is no mention of SVCCFG_CHECKHASH in svccfg(1M). Is that > intentional? Is this a private interface? SVCCFG_CHECKHASH is not new. It's been used for quite a while now to create a hash entry in the smf/manifest repository table. When this variable is set, the hash will be checked to determine if the manifest has changed and if not then do not import the manifest file. This provides a way to improve large sets of manifest import work to be imported quickly when not all manifests in the set have changed. The variable is a private interface, and we have not changed it's use from the initial integration, we are just continuing to take advantage of it. > > 2 - If I want a package that would work in builds before EMI > integration as well as builds after EMI integration and benefit from > EMI, would it make sense to deliver a manifest in /etc/svc/manifest > and place a symlink in /var/svc/manifest? Is there any recommendation > on this?
Interesting... Tom or Tony do you have an opinion here? The first thought I have is that EMI integration does not import the manifests twice, and does the correct thing with the hashing. I believe the hashing stuff would work correctly since it uses the file linked to, but we need to add this to the test matrix to be sure. > > Good work, > > Antonello > > Sean Wilcox wrote: >> Attached is the EMI ARC case for review and feedback. >> >> Thanks for your time, >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> smf-discuss mailing list >> smf-discuss at opensolaris.org > _______________________________________________ > smf-discuss mailing list > smf-discuss at opensolaris.org > > -- Sean Wilcox 303.272.9711 x79711
