Re: Autoinstall, upgrade, etc
On Thu, 11 Dec 1997, Behan Webster wrote:
> Jason Gunthorpe wrote:
Okay, I see what you are saying, so lets concentrate on this list below to
make it OK.
> > Stage 1 - Auto Upgrade - Automatically upgrade as many packages as
> > possible without violating the users wishes. Do not install
> > more packages, do not remove packages, do not upgrade to
> > anything but the install-version and do not break any packages.
> > Note - Packages with the auto flag set may be removed!
> > Stage 2 - Auto Install - Installs packages because the user wished it to
> > be so. It will install new packages, upgrade to versions other
> > than 'install-version' but it will not remove packages.
> > Note - Packages with the auto flag set may be removed!
> > Stage 3 - Safe guard - Veto the install of anything that will break the
> > system more than it already is.
> >
> > I think that summarizes my thoughts..
>
> when are packages removed in here? (i.e. a user removed a package)
Okay, that is a Stage 2 thing (Stage 2 I think is ruffly the user
interaction portion of the program, all user initiated things go in
there). Something like:
Stage 2 - <as above>
Removal will cause Deity to attempt to upgrade (or downgrade??)
other packages in an attempt to clear any conflicts with
removal. It will not automatically mark any other package for
removal unless the Replaces directive is involved. No new
packages will be installed.
Note - Packages with the auto flag set may be removed!
[Note: Replaces is going to be complex, I'm not sure how to work it in
properly]
Also, a note the line 'Note - Packages with the auto flag set may be
removed!' means that in changing this package it may cause an autopackage
to be uneeded. On reflection it should be more clear.
> Am I understanding this correctly, in that this is the rough algorithm
> that Deity will use to decide what to do, and make sure it doesn't break
> the system?
Yes, that is what I am trying to develop, something that describes the
changes to package states in the course of the program. I need to have
defined exactly what Deity can do automatically in all of the situations
that it has to deal with packages. I suppose we should send this
description to deb-devel for comments.. (Manoj?) I would like to have this
portion of the program very very specified. It's going to likely be
changed often and it is very hard to test properly - that and I sense
portions are going to be quite subtle in how the come about..
Also, I was thinking about the various 'user requests something stupid'
cases and I think I have a 3rd solution. We could put in the status bar a
field that says 'There are ## broken packages' whenever the user does
something that causes that number to go up it will beep but allow it.
There should be in the list menu an option to show all broken packages.
If the user attemps to initiate install then a warning will come up,
offering to ignore only the changes which broke things or continue as
specified.
It's pretty much what you have said, but that there will be no 'force'
options.. This way anything can be easially done to the target state
without deity getting in the way. The broken count provides a visual
indicator of how messed up things are ;> [It is most easy to implement
this way!]
How does that seem?
Thanks,
Jason
Studying Vector Calculus
Reply to: