[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Autoinstall, upgrade, etc

On Wed, 10 Dec 1997, Behan Webster wrote:

> Whoops.  I put off answering this and I forgot about it.  Sorry!

Heh, I am/is/was/continueing/whatever studying for finals so it's okay..

> To paraphrase, what happens if you try to remove a package on which
> something else still depends?  (did I understand your question
> correctly?)

> 2) If they click on the remove button, instead of selecting it for
> delete, beep and then display in the status line why it wouldn't let you
> remove this package.

I think this one is going to be simplest to do.
> In either case there should be a way to override this in the status
> window, or possibly a dialog box accessible from the status window.
> > We have lots of options, removing the packages, attempting to upgrade the
> > packages, preventing the user from making such changes, etc.
> I don't think upgrading packages is an option, and deleting the
> dependant packages is a bit too draconian for my tastes.

Well, for instance, if all your packages are set to 'bo' and your remove
libc5 upgrading everything to 'hamm' (and libc6) will correct the
> > Also, how aggresive should it be in 'upgrading' packages? For instance,
> > the very act of automatically installing a new version of 'blah' may break
> > things. Since upgrading is the default state what should happen?
> Under normal circumstances, especially the way Debian is intergrated
> (and dependencies/conflicts checked) there should never be a problem in
> installing a package.  I know this isn't always true, but I think any
> alternative to this voids most of the usefulness of an auto-upgrade
> tool.  In general, if the user upgraded last time the user wants to
> upgrade the next time.  This is the assumption on which this tool was
> designed.

Erm, no the problem comes when you try to install a package and it breaks
some other package. I am concerned about doing this because it will mess
up the install phase and the ordering. Ideally the result after running
Deity should be one with no uninstallable packages being installed. An
uninstallable package is one that will cause another package to break or
does not have it's own depends satisfied.
There are even more cases where an autoupgrade can fail, the new version
has a new dependancy that you don't have installed yet, the new version
conflicts with a package you already have, etc. 

> > Since 'Post Install' includes automatic updates, user choices and so on it
> > might have a number of problems. We can't just blindly install with
> > whatever happens to come up, they need to be solved. This is the First
> > Problem Fixing Stage.
> > [example, the automatic upgrade of libreadline causes a libreadline-dev
> >  to become invalid]
> I'm assuming that by your example there is no libreadline-dev being
> installed at the same time that would fix this problem.

Yes, there isn't a libreadline-deb avail or the one that would fix the
problem isn't avail for automatic upgrade. This is not to say that it is
impossible to install libreadline, only that it is impossible to do it
without breaking the users rules for automatic upgrade.

I'm thinking, libreadline is in hamm and wants to be auto upgraded to a
newer hamm version. But libreadline-dev is in bo and cannot be auto
upgraded. Autoupgrading libreadline would break the system and
autoupgrading would violate the users wishes, the only option seems to be
to put libreadline in keep. If the user really wants it installed (OR it
becomes interrlated with some other thing the user wants to install)  then
libreadline-dev would be selected from hamm and libreadline would be

I guess, the general rule is that no automatic action (not initiated by
the user) will break the system or violate the users preferences.

This is in contrast with what we have talked about for auto install of
deps in that the user initiates a request to install a program and the
system considers a wider range of options to install the package.

Is that consistant with the rest of the features?

> I would grey out the install button and put a message in the status
> window stating why it could not be auto installed.  If the user fixes
> the problem then the button can be ungreyed out.

Do we want to mix auto-upgrade with auto-install? I have been treating
them separately. Auto-upgrade is a gentile default action while
auto-install is a more agressive user-initiated action.

> > [Note, I just thought of these 3 stages so be kind ;>]
> Don't worry.  I think I understood perfectly.  It is a good metaphor.

Hm, let me just summarize...

 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..


Reply to: