Re: Autoinstall, upgrade, etc
On Thu, 4 Dec 1997, Behan Webster wrote:
> > So to the view of any sane person a package that depends on elf-x11r6 and
> > is installed in the system is broken. Deity should remove packages in a
> > state like this they are held with a keep-force.
>
> I'm not comfortable with this. I think that packages should only be
> auto-removed if they were auto-installed in the first place.
Okay, then we will not do that. [Note: I think dselect does do this, but
since it's remove step is not part of the install step the user has to
choice to preserve their setup ?]
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?
We have lots of options, removing the packages, attempting to upgrade the
packages, preventing the user from making such changes, etc.
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?
Basically, I need some rules on how to resolve problems. What happens in
the code is that all the dependancies for all of the versions for the
'Current' and 'Post Install' states are computed and then for each package
a flag is set if it is okay 'Current' and 'Post Install'.
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]
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]
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.]
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.
[Note, I just thought of these 3 stages so be kind ;>]
Thanks,
Jason
Reply to: