On Fri, May 16, 2008 at 05:14:32PM -0500, Shawn Walker wrote: > The "smf litter" comment is a valid one in my personal view.
So is the wheel re-invention argument. Actually, they are the same argument. > This sounds a lot like you're wanting the ability to run arbitrary > commands as part of packaging. The refresh_fmri and restart_fmri actions that Bart is working on already give you just that. Except without any structure; developers will add hodge-podge structure on top of refresh_fmri and restart_fmri. > I'm not really for that since such actions aren't really "auditable". That's like saying that letting pkgs install SMF services that get enabled is also not auditable. Well, yes, but as long as those services aren't doing things based on user input provided at pkg install time then that's OK. Also, see below about arbitrary SMF fmri method_contexts. > One of the biggest disagreements I have with most packaging/installer > mechanisms is that they don't restrict the set of possible actions, so > packages/installations are free to "run amok" amongst your system. See above. This. ship. has. sailed. (or will sail the moment we get refresh_fmri and restart_fmri actions). > If a scripting mechanism is provided, I would hope it would be either > using lua or ksh where we can completely sandbox and audit what's > happening. This isn't about scripting. Re-read my posts. For pkgs w/o their own SMF services one might want to provide a generic SMF service that can run "deferred actions" (please provide a term for this) and which runs with appropriate method_context. That, BTW, is a very good question: will IPS warn/prompt about pkgs that wish to install SMF services whose method_contexts involve running the service with privilege? This, after all, is akin to the SVR4 packaging prompt about running pkg scripts as root. > * How do you ensure that package foo does not alter or otherwise > change the configuration of package baz? Why do you want to ensure that? > * How do you ensure that these configuration actions are auditable and > reversible as part of the uninstall? (i.e. if I said uninstall, I > don't want six different configuration files littered over my system) See above. As for pkg remove, well, we've not yet had earlier questions about IPS equivalents to SVR4 pre/postremove scripting answered. Perhaps it's time to do that. > * In the cases where you intentionally have package > really_neat_apache_module alter the configuration of apache_server, > how do you record that configuration change? See above. Packages with their own services already can do whatever the heck they feel like. > * Where is the boundary between the bits that are installed and > configuration changes? In other words, how do we prevent configuration > of package foo from removing valid files for package baz? It can't be well defined. See above. > * How do we deal with "pkg verify" if package installation can alter > the delivered bits? You don't "allow" alteration of installed, non-editable/non-volatile bits. If a pkg's SMF service modifies installed non-editable/non- volatile bits, well, that's an error, and pkg verify will find it. Nico -- _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
