Shawn Walker wrote: > 2008/5/16 Jordan Brown <[EMAIL PROTECTED]>: >> That's my fear too. I suspect that the result will be that it will be >> clarified that IPS's scope is quite limited, in some areas significantly >> more constrained than pkgadd or rpm. Wearing my application provider hat, >> I'll work around that, probably by writing my own installer. Wearing my >> technologist hat, I'll be disappointed. > > You keep saying that rpm isn't constrained in the same way, how so? > > As far as I'm aware, rpm doesn't have a "partially installed" state > and has very limited tracking of the status of a package. > > It's either installed, or it isn't.
Probably true. (Like I said, extra credit if you track such a failure as an outstanding issue, e.g. through a "partially installed" mechanism.) > 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. Thinking about it, what I'd suggest as an alternative really isn't all that much of a stretch. (Heck of a lot of noise for a small change, but it *is* a key change.): Instead of explicitly relying on SMF services, have a mechanism where a package can register a command to execute after installation. Include some sort of ordering/dependency mechanism, perhaps just the package dependency mechanism, to ensure that the databases get created before the tables get added (or whatever). Retain a reference back to the package. For a live-root install, run the accumulated list of commands as the last step of the installation transaction. Report the results (including which packages they were tied to) as part of the results of the package installation. For an alternate-root install, run the accumulated list of commands as part of some IPS boot-time service. (Exactly when is an interesting question, but probably pretty early.) Collect the results. Have a user interface (probably two, GUI and CLI) to examine the results. For extra credit, alert the user on login if there were issues. In either case, it may be necessary to track dependencies and skip execution of dependent commands when their dependencies fail. Advantages (vs current IPS thinking): - Post-install failures and warnings are, for live-root installs, reported as part of the package transaction, and for non-live-root installs are reported in a single consistent way. - Application developers need not go to the work of creating and deleting one-shot SMF services. Advantages (vs rpm/pkgadd): - Post-install mechanisms are always run in the context of the appropriate root (which is current IPS design, just including it for completeness). Disadvantages (vs current IPS thinking): - More work for IPS. - Perhaps more rigid than a "pure SMF model". (But note that this mechanism does not preclude using such a model.) Disadvantages (vs rpm/pkgadd): - Failures that could be detected and reported during an alternate-root install are deferred to first boot, providing a less seamless install experience. - Post-install processing failures will not block installation of dependent packages, which could lead to obscure nested failures. 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.) _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
