On Fri, Mar 06, 2009 at 08:45:57AM -0600, Tom Mueller (pkg-discuss) wrote:
> Nicolas Williams wrote:
> >b) User images can run, either concurrently or at different times, on
> > systems running different OS versions.
> >
> > Clearly the same is not true of system images.
>
> We've been assumin
Nicolas Williams wrote:
b) User images can run, either concurrently or at different times, on
systems running different OS versions.
Clearly the same is not true of system images.
We've been assuming thus far that a user image only runs on one OS/ISA
type although this is not enforced.
On Wed, Mar 04, 2009 at 06:17:28PM -0800, Joseph Di Pol wrote:
> When time allows we'll start considering options for a simple
> cross-platform service framework for user images -- I see that
> Nicolas has posted some thoughts on this. I don't think the
> goal would be to have something as sophisti
> When time allows we'll start considering options for a simple
> cross-platform service framework for user images -- I see that
> Nicolas has posted some thoughts on this. I don't think the
> goal would be to have something as sophisticated as SMF.
In addition to Nico's suggestions, Bart wrote a
johan...@sun.com wrote:
Those who put forth the proposal read this and replied, "no we're not
going to build a service framework for user images."
The response, as you read, was that arbitrary scripting is unacceptable,
there has to be some kind of structure.
I can't speculate as to why they ca
On Wed, Mar 04, 2009 at 03:48:51PM -0600, Nicolas Williams wrote:
> It doesn't have to be a full-fledged user-image service framework. It
> doesn't have to have restarters, XML manifests, and all that. It should
> suffice to have:
>
> a) a way to register user image actuators
> b) a tool to run
On Wed, Mar 04, 2009 at 01:26:21PM -0800, johan...@sun.com wrote:
> > If that's so, then why are we not talking about correcting that
> > deficiency instead of talking about adding install-time scripting to
> > IPS?
>
> That's a fascinating question.
>
> Both Bart and I took a look at the ini
> We're talking about _user_ images in this thread. Near as I can tell
> the problem with _user_ images is the lack of an SMF action equivalent.
>
> If that's so, then why are we not talking about correcting that
> deficiency instead of talking about adding install-time scripting to
> IPS?
T
On Tue, Mar 03, 2009 at 11:22:03AM -0800, Philip Brown wrote:
> you cant DISallow it. the mechanism is there already, inherent in the
> design. As Nicole(?) acknowleged a while back, it is possible to write an
> actuator wrapper to encapsulate pretty much all postinstall scripts.
If you mean me,
On Tue, Mar 03, 2009 at 11:03:57AM -0800, Bart Smaalders wrote:
> Nicolas Williams wrote:
> >Is the issue here that there's no user image equivalent of SMF services
> >for running SMF actions?
> >
> >If so, why not hook in self-assembly at logon time?
>
> We're just trying to convince them that le
Bart Smaalders wrote:
We have had this conversation before
Philip Brown wrote:
There are some things that are purely one-shot operations unique to a
particular piece of software.
But the person packaging the software is often incapable of correctly
writing this one-shot operation in any
Nicolas Williams wrote:
On Mon, Mar 02, 2009 at 11:21:37AM -0800, Bart Smaalders wrote:
Your group needs to deliver and own packages that deliver the needed
user services on the various platforms on which you deliver. You also
need to figure out how to make this work if the platform isn't runni
On Mon, Mar 02, 2009 at 11:21:37AM -0800, Bart Smaalders wrote:
> Your group needs to deliver and own packages that deliver the needed
> user services on the various platforms on which you deliver. You also
> need to figure out how to make this work if the platform isn't running
> when the image i
On Mon, Mar 02, 2009 at 07:44:32PM -0800, Bart Smaalders wrote:
> We have had this conversation before
Yes...
> 1) You cannot run any piece of software you are installing in a
>postinstall script.
> 2) You cannot count on the architecture of the machine being the
>same.
> 3) You canno
We have had this conversation before
Philip Brown wrote:
There are some things that are purely one-shot operations unique to a
particular piece of software.
But the person packaging the software is often incapable of correctly
writing this one-shot operation in any context, perhaps excep
Bart Smaalders wrote:
Philip Brown wrote:
This is a real need. It's time to adjust the design, and drop the dogma.
The introduction of random, arbitrary scripting in packaging is a
complete failure to bound the scope of packaging operations, and
builds intimate knowledge of the current desi
Philip Brown wrote:
This is a real need. It's time to adjust the design, and drop the dogma.
The introduction of random, arbitrary scripting in packaging is a
complete failure to bound the scope of packaging operations, and
builds intimate knowledge of the current design of the system into
t
johan...@sun.com wrote:
| What we still need to write is the generic "do this on live image after
| successful install when prerequisites are met" action, which is what you
| need.
It sounds like it would be better to write the action Bart suggested,
instead of introducing arbitrary scripting
>> The examples that you've given:
>>
>> Desktop icon
>> Start menu item
>> Login start task
>>
>> All seem like common tasks that should be performed by a standard action
>> or set of actions.
>
> For those 3. Note that Bart did not agree with this approach
> last December:
>
> http
Joseph Di Pol wrote:
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 t
johan...@sun.com wrote:
The examples that you've given:
Desktop icon
Start menu item
Login start task
All seem like common tasks that should be performed by a standard action
or set of actions.
For those 3. Note that Bart did not agree with this approach
last December:
>> So in which package does the code to add a menu item belong?
>> Do all packages you want to install depend on that package?
>
> For sake of argument I have one package and it needs to add a
> menu item. It contains the code snippet to do it.
This implies that each package that needs to add a me
Bart Smaalders wrote:
Joseph Di Pol wrote:
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
Stephen Hahn wrote:
* Joseph Di Pol [2009-02-28 00:49]:
johan...@sun.com 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
e
Joseph Di Pol wrote:
johan...@sun.com 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 ca
* Joseph Di Pol [2009-02-28 00:49]:
> johan...@sun.com 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
>> eff
johan...@sun.com 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
> That's not what I'm implying. The need for actuators in user images
> simply implies the need to have package installation trigger some
> code execution -- that's the same need (or at least one of the
> needs) the SMF based implementation satisfies.
Actuators provide a way to manpiulate SMF serv
johan...@sun.com wrote:
On Fri, Feb 27, 2009 at 01:55:22PM -0800, Bart Smaalders wrote:
>> ...
I'm not exactly sure why this is needed, since the commands invoked as
side effects run w/ the same priv. level as the components that are
being run from the image this seems to propose a rich s
Responses below:
Bart Smaalders wrote:
Joseph Di Pol wrote:
I have created the following RFE:
6994 Need actuator implementation for user images
http://defect.opensolaris.org/bz/show_bug.cgi?id=6994
Joseph Di Pol wrote:
The Update Center team has a need for a cross-platform Actuator
implem
On Fri, Feb 27, 2009 at 01:55:22PM -0800, Bart Smaalders wrote:
> Joseph Di Pol wrote:
>>
>> I have created the following RFE:
>>
>> 6994 Need actuator implementation for user images
>> http://defect.opensolaris.org/bz/show_bug.cgi?id=6994
>>
>> Joseph Di Pol wrote:
>>>
>>> The Update Center team h
Joseph Di Pol wrote:
I have created the following RFE:
6994 Need actuator implementation for user images
http://defect.opensolaris.org/bz/show_bug.cgi?id=6994
Joseph Di Pol wrote:
The Update Center team has a need for a cross-platform Actuator
implementation that supports User Images.
Tom a
I have created the following RFE:
6994 Need actuator implementation for user images
http://defect.opensolaris.org/bz/show_bug.cgi?id=6994
Joseph Di Pol wrote:
The Update Center team has a need for a cross-platform Actuator
implementation that supports User Images.
Tom and I have put together
Responses below...
Stephen Hahn wrote:
* Joseph Di Pol [2009-02-18 18:14]:
The Update Center team has a need for a cross-platform Actuator
implementation that supports User Images.
Tom and I have put together a proposal that we'd like to get
feedback on:
http://wiki.updatecenter.java.net/Wi
* Joseph Di Pol [2009-02-18 18:14]:
>
> The Update Center team has a need for a cross-platform Actuator
> implementation that supports User Images.
>
> Tom and I have put together a proposal that we'd like to get
> feedback on:
>
> http://wiki.updatecenter.java.net/Wiki.jsp?page=UC22UserImageActua
Ed McKnight wrote:
Hi Joseph,
Why exclude this concept from os image? You're proposing a new actuator,
so why speak of "replace" service frmi's?
thx, --emk
Ed,
It's my understanding that the proposed UserImageActuator implementation
may not be acceptable for use on an OpenSolaris system im
Hi Joseph,
Why exclude this concept from os image? You're proposing a new actuator,
so why speak of "replace" service frmi's?
thx, --emk
Joseph Di Pol wrote:
The Update Center team has a need for a cross-platform Actuator
implementation that supports User Images.
Tom and I have put toget
The Update Center team has a need for a cross-platform Actuator
implementation that supports User Images.
Tom and I have put together a proposal that we'd like to get
feedback on:
http://wiki.updatecenter.java.net/Wiki.jsp?page=UC22UserImageActuators
Keep in mind this implementation would only
38 matches
Mail list logo
