[indiana-discuss] "no scripting zone" and isaexec(3C) == architectural

[Bernd Schemmer]

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