Stephen Hahn wrote:
* Joseph Di Pol <[email protected]> [2009-02-28 00:49]:
[email protected] wrote:
The current SMF Actuator implementation provides the ability for
a package installation (or removal or update) to trigger code to be
executed.
The actuators don't exist to execute code, you've reversed cause and
effect.
But they do provide that capability. And they've been proposed
as a solution if none of the other "you-don't-need-package-scripts"
solutions are practical.
So let's look at an example:
When the user installs my application into a user image I want an icon
to appear on the user's desktop. I need to support Linux, Mac,
Windows, etc.
How can I do that?
But I think I have a valid need here. And I think the
UserImageActuator is a reasonable compromise. I know it's not
perfect, and the SMF implementation is more robust. But I also think
the requirements and risk/benefit trade offs are different for
user images than for system images.
Why wouldn't
file ... desktop_icon=true
with known safe handling be sufficient? The point that's being made
is that arbitrariness implies lack of safety. How many use cases are
known at this time?
Off the top of my head (I will work on gathering more):
Desktop icon
Start menu item
Login start task
Unbundled GlassFish 2 configuration initialization (improved in v3).
Also the open-ended issue wrt software we don't control (and possibly
can't predict) that requires some kick or config tweak when adding
a plugin, module, etc.
I understand the concern that arbitrariness implies lack of safety.
But relying on the creation of new actions (or action behaviors)
for things we can't predict implies lack of agility and flexibility.
And I would claim that this will have more of a negative impact on
users than the potential risks posed by UserImageActuators.
Joe
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
