[EROS-Arch] Package handling...

trey@treysoft.com trey@treysoft.com
Wed, 28 Mar 2001 08:02:13 -0600


On Wed, Mar 28, 2001 at 08:42:30AM -0500, Jonathan S. Shapiro wrote:

[ sorry for any extra copies, as I don't know who in the To:/Cc: list
subscribes to the list ]

> Forget about the security implications for a moment. Consider first the
> implications of warranty.
> 
> If I build a program that relies on a component, I have tested my
> program against a particular version of that component. The updated
> component may be better, but it may or may not have been tested under
> the same assumptions as my program, and it may or may not *work* in my
> program. Therefore, the component must not be updated in the context of
> my program until my program agrees to the update.
> 
> This means that update must be performed on a "pull" rather than a
> "push" model. My application must somehow be notified that an update is
> available, and must then decide whether to accept it or not.
> 
> Update is an option that wants to remain open. You may ship an update.
> The application vendor may later test it and say "okay, that update is
> okay for my app". The app vendor may then ship an app patch that says
> the update is okay, after which the app may consent to the update.
> 
> However, forcible update is not the right thing.
> 
Agreed.  In fact you will have to support multiple versions of components,
as the probability that multiple vendors using the some shared component
will all validate the new version simultaneously approaches zero.

-- 
Trey Boudreau