[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?
Drop a file into the right spot so Gnome/Windows/whatever adds
it to the desktop? Nope -- I'm installing into a user image.
Can't drop a file anywhere but in the user image.
Create a new action? No go. Floated that by in December
and the response was that the packaging system should not have detailed
knowledge of desktop integration. I agree, pkg(1) code should not
have knowledge of gnome interfaces, Mac OS desktop interfaces, etc.
Use an SMF service and the current actuator implementation?
Can't. I can't drop a file outside of my user image to install
the service. Oh, and I'm on Windows.
Have your GUI installer do it? Well, this packages is almost
always added on later from a repo. No installer in the
picture.
All I need is a little fire-and-forget hook after the files
are safely installed. That's what UserImageActuator provides.
I understand the objections to package scripting. I understand
the motivations for the SMF Actuator implementation. I understand
how great actions are. Really, I do.
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.
Joe
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
