On Mon, Nov 16, 2009 at 01:18:22PM -0800, David Powell wrote: > 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.
As a former customer for many years, /etc was the first place I would look for general configuration information like this. While I understand manifests are considered more definition than configuration information, as an Admin I would still expect to see this information in /etc than in /lib. BJ -- B.J. Wahl Solaris Kernel Development
