On Mon, Jun 15, 2009 at 06:17:51PM +0200, Bernd Schemmer wrote:
> >>That is far from a given. In the short run, it requires some
> learning, but in the long run it will be a more stable execution
> environment than any sort of >>scripting in SVR4 packages ever provided.
>
> Hmm, I'm not sure about that . But anyway - if this is the way to go we
> have to use it.
The reason the IPS approach is simpler has been explained entirely too
many times :)
> What about the preinstall scripts, and post/pre remove scripts?
My SVR4->IPS CAS and post* script migration prototype shows how one can
use the IPS SMF actuator approach to implement CAS and postinstall/
postremove. (If nothing else, you can always keep using SVR4 CAS and
post* scripting and adapt my SVR4->IPS migration prototype to your
needs.)
The only way that one could implement preinstall/preremove[*] would be
by breaking up pkgs into pieces that must be installed/removed in a
specific order, and that's just not practical. And, of course, there's
no way whatsoever to do anything like 'checkinstall' and 'request'
scripting in IPS -- which I do believe is a good thing.
I'm not sure why one would need preinstall at all; in SVR4 packaging
most of the things one might want to do in preinstall belong to
checkinstall, and anything beyond that (e.g., anything involving use of
installf/removef, or editing files) strikes me as a bug in the package.
With IPS facets and variants I also don't see any need to have
checkinstall scripting.
Typical uses of SVR4 preremove scripting can be replaced with specific
IPS features. For example, driver removal. Or to prevent removal of a
pkg that's unsafe to remove from running images while still in use. IPS
must (and mostly, if not entirely does) support these uses of preremove
directly.
Thus, not only is there no practical way to emulate SVR4 preinstall/
preremove/checkinstall pkg scripting with IPS, there's no reason to.
Similarly, much of what request scripts often do can be replaced with
IPS functionality, such as facets and variants. (I'm not entirely sure
how relocatable pkgs / user images work in IPS, or how to use such
features.)
[*] One might be tempted to use an SMF actuator to implement preremove
functionality when removing a pkg from a running image, but how's
the service to distinguish between "disabled by the sysadmin" from
"disabled by IPS ahead of update" and "disabled by IPS ahead of
removal"? Even if SMF added a plethora of methods to allow for
these distinctions, such actuators would never run on removal from
an inactive image.
Nico
--
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
