2008/5/16 Jordan Brown <[EMAIL PROTECTED]>: > Shawn Walker wrote: >> Yes it allows you to run arbitrary scripts during the install process, >> but that functionality isn't really rpm, that's what the program is >> providing. > > Rpm and pkgadd supply frameworks for running program-provided scripts and > reporting their results to the user. Granted, that framework has > constraints, but it is sufficient for many or most purposes. (And yes, the > framework for reporting the results back to the user is trivial, > stdout/stderr, but that's what's nice about simplicity.) > > IPS is sort of, kind of, providing a framework for running user-provided > code, but is not providing any reasonable way to get the results back to the > user. Plus, absent additional complexity for the packager, it has the bonus > of leaving around litter in the form of SMF services that are only needed > once.
The "smf litter" comment is a valid one in my personal view. > Instead of explicitly relying on SMF services, have a mechanism where a > package can register a command to execute after installation. Include some This sounds a lot like you're wanting the ability to run arbitrary commands as part of packaging. I'm not really for that since such actions aren't really "auditable". 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. 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. In short, because so many packaging/installer systems today allow for arbitrary command execution, install/uninstall operations have the potential to leave various litter strewn about; amongst other unwholesome actions. > Issues: > - Perversely, applications like SMF that do what we would now consider to be > a good job of handling these cases may be second-class citizens, because > their first-boot error reporting won't go into the common "install failure" > report. They are no worse off than they are today, but may not be as good > as applications using this mechanism. (OTOH, perhaps the "manifest" class > action script devolves into a deferred "svccfg import", instead of relying > on the manifest directory scan, and that *would* be handled well.) There are some other issues here as well: * How do you ensure that package foo does not alter or otherwise change the configuration of package baz? * 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) * 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? * 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? * How do we deal with "pkg verify" if package installation can alter the delivered bits? -- Shawn Walker "To err is human -- and to blame it on a computer is even more so." - Robert Orben _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
