Hi,
Thus, not only is there no practical way to emulate SVR4 preinstall/
preremove/checkinstall pkg scripting with IPS, there's no reason to.
That's the reason why I don't like the new approach:
"Someone" decided what is useful and what not and we have to live with
it ...
When I compare IPS with SVR4 I would call SVR4 "freedom to implement the
best solution for your situation even if Sun never thought that it might
be used this way" and IPS "you're only allowed to do what we think is
useful".
Nevertheless I think IPS is useful for Solaris running on a desktop
computer (I'm using OpenSolaris on my Thinkpad for day-to-day usage and
I'm very satisfied with Solaris and IPS there) but I don't think this is
the right way to go for server in production.
regards
Bernd
Nicolas Williams wrote:
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
--
Bernd Schemmer, Frankfurt am Main, Germany
http://bnsmb.de/
M s temprano que tarde el mundo cambiar .
Fidel Castro
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
