Sean Wilcox wrote:
> Attached is the EMI ARC case for review and feedback.
I have a simple question about this:
> Manifest files will be imported from a new location that is available
> at the time Early Manifest Import is executed. Root (/) will be
> available, and as part of that /etc will be available. Therefore
> manifest files located under /etc/svc/manifest and /etc/svc/manifest/site
> will be imported during the execution of Early Manifest Import.
> As part of this project, the ON manifest files that are currently
> delivered under /var/svc/manifest will be moved to /etc/svc/manifest.
> Going forward it will be recommended best practice that manifest files
> be delivered under /etc/svc/manifest subtrees to take advantage of
> Early Manifest Import.
Why /etc/svc/manifest?
I'm not saying we shouldn't move where manifests are read from; the
problems with /var are unavoidable. But /etc seems like the wrong
destination. Service manifests are definition, not configuration,
but /etc is:
Platform-dependent administrative and configuration
files and databases that are not shared among systems.
/etc may be viewed as the directory that defines the
machine's identity.
In addition to being the documented purpose of /etc, I venture to say
this is an accurate description of how customers view /etc as well.
I think we've done a great job of dispelling the notion that
manifests are editable configuration, but moving them to /etc seems
at best to be an unnecessary test of our success.
Since the root/usr split unfortunately still exists, alternatives are
limited. What about /lib/svc/manifest?
Dave
