Re: Autoinstall, upgrade, etc
Whoops. I put off answering this and I forgot about it. Sorry!
Jason Gunthorpe wrote:
>
> There is another problem I'm not too sure how to solve. What do we do when
> the user changes something (install/remove) and it effects other packages?
>
> Simple example, removing libc5 with other libc5 packages. What should
> happen here?
To paraphrase, what happens if you try to remove a package on which
something else still depends? (did I understand your question
correctly?)
I would say we have a couple of possibilities:
1) grey out the delete button so that they can't remove the package. If
the pointer goes over this button put a message in the status bar saying
why it can't be removed. (This isn't a very optimal solution however)
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.
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.
> 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.
In the development stream (unstable) the developpers that are installing
packages know how to fix problems with packages and those who don't
(quite frankly) deserve what they get. It is "unstable" after all.
> 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.
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.
> The Second Problem Fixing Stage would be when the use does something. This
> will require any problems caused by the user aciton to be resolved.
> [exmaple, the user checks the install checkbox on gv]
We've discussed these sorts of problems already I believe...
> The Thrid Problem Fixing Stage is directly after the 'go' button is
> pressed. Anything that would break something that wasn't broke before
> would have to be removed from the install list. I don't think we want to
> tell dpkg to do something that may hose the users system. After dpkg is
> run the system should not be more broken than it currently is
> [Theoretically this is not needed, but if some of these 'force' things are
> used then it might be necessary? At the very least it is a safe guard
> against code bugs.]
True.
> Mostly we have been talking about the 2nd Stage, installing packages where
> necessary, the auto flag and so on. No one has talked about the first
> Stage though.
True.
> [Note, I just thought of these 3 stages so be kind ;>]
Don't worry. I think I understood perfectly. It is a good metaphor.
I hope I answered your questions satisfactorily.
Later!
Behan
--
Behan Webster mailto:behanw@verisim.com
+1-613-224-7547 http://www.verisim.com/
Reply to: