Sean Wilcox wrote: > 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. >
Agreed, I'd expect svccfg to resolve the symlink and create manifestfile property groups for the real file, similar to how we track hashes for profiles. As to best practice, anxious service creator :) can do this but should remove the symlink in /var/svc/manifest once EMI is integrated. We should definitely add this to our test matrix. -tony
