Nicolas Williams wrote: > On Mon, Nov 16, 2009 at 04:40:07PM -0800, Jordan Brown wrote: >> David Powell wrote: >>> What about /lib/svc/manifest? >> Sounds right to me. >> >> B.J. Wahl wrote: >>> 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. >> But manifests are _not_ configuration, and any perception that they are is >> a bug that needs to be corrected. Keeping them _out_ of /etc helps to >> avoid that perception. > > +1 (Manifests are delivered by pkgs, and what pkgs are installed can be > seen as a sort of configuration, but I think nonetheless that it's best > to think of manifests as not configuration.) > > I think the fact that we already have /etc/svc may have led you to > putting the EMI manifests there, but it really belongs not in /etc. > > It's important to not mix configuration with non-configuration. Being > able to separate configuration from non-configuration was important to > the Sun 7xxx storage appliance folks (who, IIUC, had to do a fair bit of > surgery to get the system to run with read-only / and SMF repos off in > /var). I know we're not really there now, but it'd be nice if we could > get there eventually. Adding non-config contents to /etc is less bad > than adding config contents outside /etc, but still (and ephemeral > contents belongs in /var/run; death to PID files in /etc! death to PID > files!). >
The other point Dave made offline is that we'd add a load of static files into /etc which would unnecessarily increase backup burden for some folks. Since we already have /lib/svc/method, having manifests under /lib/svc/manifest is very reasonable. The project will revisit this design detail and get back to the alias on our decision. Thanks, -tony
