[EROS-Arch] Package handling...

[Joerg Bornschein]

On Wed, Mar 28, 2001 at 04:40:33PM +0200, Pascal J. Bourguignon wrote:

Hello,

> > 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.
> 
> I don't  know. I see  a little this  installation phase as  setting up
> links between collections of  objects. Therefore, it should not import
> too much to a certain object A  to be connected to some other object X
> or  Y,  _as_long_as_  these  objects  implements  the  same  interface
> specified for the object A.

You are right, it _should_ work. But (at least to me) it prooves about
once a (week|month) not to be this way :(

I don't think the arrival of a new component version a sufficient reason
to fiddle with all those constructors using this component.

I think the right thing to do is: build new constructors for your
 application and hand it out to your users (or yourself) and see if
 the updated application works as expected.

If it works, fine! Announce that you will delete the old version in n 
hours.
It does not work? Ok, write a mail to your favourit vendor and say:
"your X does not do Y when i update Z to Z+1". In the meantime everything
is as it was before.

I think that's the way i want my computer to be...


> If an  applications wants to  be installed with  a capacity to  read a
> file, I think the administrator and/or the user should be free to give
> it a capacity to read a local device, a remote file or device, or from
> a "pipe"  or whatever, as long as  the interface is the  same (and the
> syntax of  the data read matches).  (Of course the  definition of such
> interfaces should  include pre & post  conditition so it's  not only a
> syntax, but also some semantic that is specified).

IMHO, applications should simply use the capabilities handled to them if
they support the right interface. E.g: of course i want my application 
to work if i handle them a "faked" daytime service in order to find a
timezone handling bug..

But the installation of "fake-daytime v0.1" should IMHO not alter applications
using "daytime" until i explicit build a application constructor linked
"fake-daytime".

    joerg