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

[Nicolas Williams]

On Wed, Jun 10, 2009 at 12:00:35AM -0700, UNIX admin wrote:
> To the best of my knowledge and belief, as of right now, SMF provides
> no capability for a one time run, so getting post-installation code to
> run via SMF is tricky, with one svcadm refresh, and one svccfg delete.

This thread's been beat to death, but what the heck :)

It is definitely possible to build one-shot SMF services, as well as
transient services that do nothing when there's nothing for them to do.
I've done it as a proof of concept.  A service can disable itself.  And
a service can even remove itself.  Because SMF out of the box doesn't
provide a way to do the latter it took some cleverness, namely: use
ctrun(1) with an argument command that is, effectively, a shell script
that waits for the service's state to change to offline then removes the
service, all the while the parent disables the service.

> Is it really practical to take the "no scripting zone" design so far
> as to force people to resort to "backdoors" and hacks via SMF, which
> SMF doesn't even rightly support yet? I mean, if I have to use SMF to
> do postinstall, I clearly have the need to execute code upon software
> installation and removal. Why refuse to give me capability to do that
> in the packaging system?

The IPS team's arguments for no pkg install/remove time scripting are,
IMO, rock-solid.  I would prefer that there were more examples and
better conventions and tools around self-assembly, but that's nothing
compared to what IPS solves just by not allowing install-time scripting.
Any engineer who's had to fix SVR4 package class action scripts knows
this deep down.

Nico
--